【ITニュース解説】IDENTITY PROVIDERS

システム開発の世界では、様々なシステムやサービスが連携し、複雑な仕組みを構成している。その中で、誰がどのサービスにアクセスして、何ができるのかを管理することは非常に重要だ。AWS (Amazon Web Services) では、このアクセス管理の中心的な役割を担うのがIAM (Identity and Access Management) というサービスだが、今回はその中でも特に「IAM Identity Provider（アイデンティティプロバイダー、略してIdP）」という仕組みについて詳しく解説する。

まず、なぜこのIdPという仕組みが必要なのか。AWSを利用する際、通常はIAMユーザーを作成し、そのユーザーに対してアクセス権限を付与する。しかし、企業で働く何百、何千人もの従業員全員に対してAWS上にIAMユーザーを作成し、その認証情報（ユーザー名とパスワード）を管理するのは非常に手間がかかるし、セキュリティ上のリスクも高まる。従業員が退職するたびに、IAMユーザーを削除するなどの運用も煩雑だ。

そこで登場するのがIdPだ。IdPは、AWSの外部にある信頼された認証システムとAWSを連携させる仕組みである。例えば、会社で使っているOktaやAzure Active Directoryといった従業員管理システムや、個人のGoogleアカウント、GitHubアカウントなど、すでに持っている認証情報を使ってAWSにアクセスできるようにする。これにより、AWS上に個別のIAMユーザーを作成する必要がなくなり、認証情報の管理が外部のIdPに一元化される。ユーザーは普段使い慣れている外部のシステムで認証し、その認証情報を使って一時的にAWSの「ロール」を引き受け、AWS内のサービスを利用できるようになるのだ。この一時的な認証情報の取得には、AWSのSecurity Token Service (STS) というサービスが利用される。

IdPにはいくつかの種類がある。企業向けの認証システムと連携する場合には「SAML 2.0」という標準的なプロトコルがよく使われる。Okta、Azure Active Directory (Azure AD)、ADFS (Active Directory Federation Services) などがこれに該当する。一方、ウェブアプリケーションやモバイルアプリなど、モダンなアプリケーションで利用されるのが「OpenID Connect (OIDC)」だ。Google、GitHub、Auth0などがOIDCに対応している。また、AWS自体も「Cognito」というマネージドなサービスを提供しており、これを使うことでソーシャルログイン（Google、Facebookなど）もサポートするIdPを簡単に構築できる。さらに、「Web Identity Federation」という、STSのAssumeRoleWithWebIdentityというAPIを直接利用する方式もある。

IdPと連携するAWSのIAMロールを理解するには、「Trust Policy（信頼ポリシー）」と「Permission Policy（許可ポリシー）」の二つのポリシーを区別することが重要だ。Trust Policyは、そのロールを「誰が引き受けることができるのか」を定義する。つまり、外部のどのIdPからの認証を受けたユーザーが、このロールを利用することを許可するのかを設定するのだ。例えば、特定のSAML IdPからの認証を受けたユーザーのみがロールを引き受けられるように設定する。一方、Permission Policyは、そのロールを引き受けたユーザーが「AWS内で何ができるのか」を定義する。具体的には、S3バケットへの読み書き、EC2インスタンスの起動など、AWSの各種サービスに対する操作権限を指定する。この二つのポリシーが組み合わさることで、外部の認証システムと連携しつつ、AWS内でのアクセス権限を細かく制御できるわけだ。

IdPの利用には多くのメリットがある一方で、設定ミスによるセキュリティリスクも存在する。よくある問題として、SAMLメタデータの誤設定、例えば証明書の期限切れや情報不一致が挙げられる。また、Trust Policyを過度に広く設定してしまうと、意図しない外部ユーザーにロールを引き受けられる危険がある。多要素認証 (MFA) が強制されていない場合や、ロールのセッション期間を非常に長く設定してしまうと、認証情報が漏洩した際のリスクが増大する。これらの問題を避けるためのベストプラクティスとしては、常に短期間のみ有効な認証情報（セッション期間は最大でも12時間程度）を使用すること、IdP側とAWS側の両方でMFAを強制すること、IdPのグループとAWSのロールを適切にマッピングし、最小限の権限のみを付与すること、SAMLやOIDCのメタデータや証明書を定期的に更新すること、そしてAWSのCloudTrailでSTSのAssumeRoleイベントを監視し、不正なロールの引き受けがないか常にチェックすることが挙げられる。

具体的な活用例として、GitHub Actionsを使ってS3バケットにファイルをアップロードするケースを考えてみよう。GitHub Actionsは、コードの変更を検知して自動的にビルドやデプロイを行うためのサービスだ。通常、GitHub ActionsからAWSにアクセスするには、AWSのアクセスキーをGitHub側に秘密情報として保存する必要があるが、これは長期間有効な認証情報を外部に置くことになるため、セキュリティリスクがある。そこでOIDC IdPを活用するのだ。

まず、AWSのIAMコンソールでOIDC IdPを作成する。ここで、GitHubのOIDCプロバイダーのURL（https://token.actions.githubusercontent.com）と、AWSのオーディエンス（sts.amazonaws.com）を設定する。これにより、AWSはGitHubからの認証トークンを信頼するようになる。次に、GitHub Actionsが引き受けるためのIAMロールを作成する。このロールのTrust Policyには、特定のGitHubリポジトリから、特定のブランチ（例えばmainブランチ）からのリクエストのみがロールを引き受けられるように条件を設定する。これにより、AWSアカウントID、GitHubのユーザー名、リポジトリ名を指定することで、アクセスを厳密に制限できる。このロールが引き受けるアクションはsts:AssumeRoleWithWebIdentityとなる。その後、このロールにはS3へのファイルアップロードに必要な権限（例えばAmazonS3FullAccess）をPermission Policyとして付与する。最後に、GitHubリポジトリ内にワークフローファイル（.github/workflows/deploy.ymlなど）を作成する。このワークフローファイル内で、id-token: writeというパーミッションを設定し、aws-actions/configure-aws-credentialsアクションを使って、先ほど作成したIAMロールを引き受けるように設定する。そして、aws s3 syncコマンドなどでS3バケットにファイルをアップロードする処理を記述すれば、長期間有効なAWSの認証情報をGitHubに保存することなく、GitHub ActionsからセキュアにAWS S3にアクセスできる。

このように、IdPは様々な業界で活用されている。スタートアップ企業では、開発者がGoogle OIDCを使ってAWS CLIにアクセスすることで、開発環境へのアクセスを簡素化している。大企業では、OktaなどのSAML IdPをAWS Organizationsと連携させ、ビジネスユニットごとにAWSのロールをマッピングすることで、大規模なユーザー管理とアクセス制御を実現している。金融業界では、PCI DSSやSOXといったコンプライアンス要件を満たすために、SAML IdPとの連携ロールにMFAを強制している例がある。また、DevOpsチームでは、GitHub ActionsのOIDC連携を活用し、長期間有効なシークレットを配置せずにAWSリソースをデプロイしている。

IAM Identity Providerは、外部の認証システムとAWS IAMの間の架け橋となる非常に強力な仕組みだ。これを利用することで、長期間有効なIAM認証情報の必要性をなくし、フェデレーションされたセキュアでスケーラブルな認証を実現できる。Trust PolicyとPermission Policyを正しく理解し、短期間のセッションとMFAを強制し、そして常にフェデレーションイベントを監視・監査することが、 IdPを安全に運用するための鍵となる。