AWS を自治体基幹業務システムのように閉じたネットワークで使う時、パブリッククラウドの経験が少ない自治体情シスとして最初に戸惑ったことは、AWS 環境で行われる認証認可の仕組みでした。
AWS でインフラストラクチャを構築すると、AWS のリソースを操作する際に様々な認証認可が求められるのですが、ガバメントクラウドの AWS で自治体基幹業務システムを運用するにあたっては、主に以下の場面で認証認可が登場します。
- 職員やベンダーの担当者が、AWS リソースを操作するユーザーとしてマネジメントコンソールへサインインするとき
- AWS リソースそのもの（EC2 インスタンスや Lambda 関数など）が、個人情報を含むファイルを連携するために、別の AWS アカウントにある S3 のバケットにアクセスするとき
- オンプレミスや AWS 以外の Cloud Service Provider のサーバーなどが、個人情報を含むファイルを連携するために、S3 のバケットにアクセスするとき
これらの場面で使われる認証認可の仕組みを理解しておくことは、インシデント発生時の対応やベンダー間の調整の時の助けになると思います。
特にここで出てくる IAM ロール、IAM ポリシーの仕組みを覚えることは、AWS でインフラを構築する際の重要なセキュリティの要素を知ることになりますので、これらの知識は自治体情シスもぜひ押さえておきたい知識の一つです。
そこで、これらの場面に的を絞って、ガバメントクラウド AWS 環境で主に使われる認証認可の仕組みを解説してみたいと思います。
本記事は ガバメントクラウド Advent Calendar 2025 の 3 日目の投稿となります。
前提知識としての Identity and Access Management (IAM) とは
AWS の Identity and Access Management (IAM) を簡単に説明すると、ある AWS のリソースにアクセスしようとしているものが、
- 誰（ユーザー）・何（インスタンスなどのリソースや AWS の他のサービス）であるか認証する
- 認証されたものが対象の AWS リソースに対して権限を有していればアクセスを許可する
仕組みをマネージドサービスとして提供しているものです。AWS のドキュメントでは以下のように説明されています。
AWS Identity and Access Management (IAM) は、AWS リソースへのアクセスを安全に管理するためのウェブサービスです。IAM を使用すると、ユーザーがアクセスできる AWS のリソースを制御するアクセス許可を管理できます。IAM を使用して、誰を認証 (サインイン) し、誰にリソースの使用を認可する (アクセス許可を付与する) かを制御します。IAM は、AWS アカウントの認証と認可を制御するために必要なインフラストラクチャを提供します。
AWS でシステムのインフラを構築し運用するために必要な AWS リソースに対する認証認可は、IAM を通じて行うことが基本です。
IAM ユーザーとは
情シスであれば一番馴染みのある認証認可の仕組みは、ユーザー認証ではないでしょうか。AWS の IAM にも IAM ユーザーというユーザー認証の仕組みが用意されています。
IAM ユーザーを作成し、IAM ユーザーに対して必要なアクセス権を後述する IAM ポリシーで定義して割り当てることで、IAM ユーザーによる認証認可が実現できます。
IAM ポリシーとは
IAM ポリシーとは、IAM ユーザーなどの認証された対象が、どんな条件で、どのリソースに対して、何のアクション（読み取りや書き込みなど）を許可又は拒否するのかについて定義するものです。
IAM ポリシーを IAM ユーザーに割り当てることで、認証された IAM ユーザーが操作しようとする対象の AWS リソースに対して IAM ポリシーで定義された認可を得られる仕組みです。
（説明がややこしくなるため、本記事においてインラインポリシーについては触れません。）
IAM ユーザーはガバメントクラウドでは原則使えない
ガバメントクラウドにおける AWS リソースへの認証認可は IAM ユーザーを使うのでしょうか？
答えは No です。実はガバメントクラウドでは、原則 IAM ユーザーを使用することができません。
IAM ユーザーを使った認証認可は、AWS ではベストプラクティスとされていません。なぜなら、IAM ユーザーを使用すると長期間の認証情報を保持することができるのですが、これを逆手に取ると IAM ユーザーの情報が外部に漏れてしまうと、外部から AWS リソースへの侵害が可能となってしまいます。
そのため、ガバメントクラウドでは、原則 IAM ユーザーを使った長期間の認証情報の使用が許可されていません。
それではガバメントクラウドの利用者は、IAM ユーザーを使用せずにどうやって認証認可を実現すればよいでしょうか？
IAM ロールでの認証認可
ここで IAM ロールが登場します。IAM ロールとは、IAM ユーザーのような認証の対象の一つで、IAM ポリシーを割り当てることで AWS リソースへの認可を行うことは一緒です。しかし、IAM ユーザーと IAM ロールの大きな違いは以下のとおりです。
- IAM ユーザーのようにパスワードで認証するのではなく、IAM ロールを引き受ける対象が認証情報（クレデンシャル）を得られる仕組み
- IAM ロールで払い出されるクレデンシャルは一時的なものであるため、万が一クレデンシャルが外部へ漏えいしても長期間にわたって外部から侵害され続けるリスクは低減される
IAM ロールを引き受ける（Assume Role する）対象は、IAM ロールへ定義されたポリシーに沿った認可が得られる仕組みです。
IAM ロールを引き受けられる対象は、後述する IAM Identity Center でフェデレーションされた認証ユーザー（IAM ユーザーとは全く異なるので注意）や、AWS のサービス（EC2 や Lambda など）で、事前に当該 IAM ロールを引受け可能な対象を定義（信頼関係と言います）しておくことで、認めていない対象が当該 IAM ロールを引き受けられないようにすることができます。
つまり IAM ロールには、以下の 2 つの機能が認証認可の要素となっています。
| 機能 | 役割 | 設定する対象 |
|---|---|---|
| 信頼関係 | この IAM ロールは誰（何）が引き受けてよいかを定義 | IAM Identity Center のユーザーや AWS サービスなど |
| 許可ポリシー | この IAM ロールが許可する IAM ポリシーを定義 | IAM ポリシー |
図にすると以下のようなイメージです。
Security Token Service (STS) と Assume Role について
IAM ロールには、引き受けた IAM ロールを使って別の IAM ロールを引き受ける、という使い方があります。
IAM ロールの引受けには、AWS Security Token Service (STS) というサービスが重要な役割を担っています。
具体的には、現在引き受けている IAM ロールのクレデンシャルを使って STS にアクセスし、現在引き受けている IAM ロールからの Assume Role を許可する信頼関係が設定されている別の IAM ロールを引き受け、STS からこの IAM ロールの一時的なクレデンシャルを受け取ることができます。
IAM ロールと、STS による Assume Role の仕組みを押さえれば、少なくともガバメントクラウドで自治体基幹業務システムを運用するのに必要な AWS リソースへの認証認可の基本的な部分が理解できていると言えるのではないでしょうか。
それでは IAM の仕組みを踏まえて、具体的なガバメントクラウド AWS 環境における認証認可の仕組みを見ていきましょう。
マネジメントコンソールへのアクセス
EC2 インスタンスを起動したり、S3 にバケットを作成したりといった AWS 環境を操作する方法はいくつかありますが、マネジメントコンソールを使う方法は馴染みがあると思います。
マネジメントコンソールへの一般的なログイン方法は 2 通りの方法があります。
1 つ目はルートユーザーと呼ばれる AWS アカウントを作成する際に作られるユーザーや、IAM で作成する IAM ユーザーを使ってログインする方法で、2 つ目は AWS IAM Identity Center という認証機能を使ってシングルサインオンする方法です。
しかし、ガバメントクラウドでは、前者のルートユーザーや IAM ユーザーでのマネジメントコンソールへのサインインは認められておらず、後者の IAM Identity Center を使って、外部 Identity Provider (IdP) からフェデレーションされたユーザーでの認証が必要ですす。
Government Cloud Assistant Service (GCAS) との連携によるユーザー認証
フェデレーションする外部 IdP は、Government Cloud Assistant Service (GCAS) というデジタル庁が管理する基盤にあるユーザー認証機能です。ガバメントクラウドでは、GCAS にアカウントを作成することで、Cloud Service Provider (CSP) 環境へシングルサインオンができるようになっています。
IAM Identity Center の許可セットによる認可
IAM Identity Center には許可セットという機能があり、認証されたユーザーがどの AWS アカウントの、どの IAM ロールの引受けを許可するかを定義することができます。
ガバメントクラウドでは、GCAS でのユーザー設定により、強い管理者権限を持つ「AWSAdministratorAccess」許可セットか、他の IAM ロールへの Assume Role のみが許可された「SwitchOnlyRole」許可セットのいずれかが割り当てられます。
いずれの許可セットを割り当てられたとしても、Assume Role した先の AWS アカウントには、必要な権限のみを設定したポリシーを定義した IAM ロールを作っておき、この IAM ロールへ Assume Role する運用が必要です。
ガバメントクラウドでマネジメントコンソールへアクセスする方法のまとめ
ガバメントクラウドの AWS でマネジメントコンソールへアクセスして操作する方法をまとめると次のとおりです。
- GCAS ユーザーで認証し、AWS のマネジメントコンソールへシングルサインオンする
- 許可セットにて引き受けた IAM ロールから、必要な権限が設定された IAM ロールへ Assume Role する
S3 バケットへ別の AWS アカウントのリソースからアクセス
次は S3 バケットへのアクセス方法について見ていきます。
S3 バケットポリシーによるIAM ロールを使ったアクセスの認可
S3 バケットへのアクセス権限の管理にはバケットポリシーという機能を使います。バケットポリシーに設定できる条件は様々ですが、ここでは、これまで見てきた IAM ロールを使い、特定の IAM ロール（当該 S3 バケットへの操作が許可されたポリシーがアタッチされた IAM ロール）のクレデンシャルを持っているクライアントのみが対象のバケットへアクセスできるようにできます。
バケットポリシーはバケットごとに、JSON 形式で設定します。特定のバケットに対して特定の IAM ロールに一部の S3 操作を許可するバケットポリシーのサンプルは次のとおりです。
{
"Version": "2012-10-17",
"Statement": [
{
"Sid": "Allow-access-to-specific-IAM-role",
"Effect": "Allow",
"Principal": {
"AWS": "アクセスを許可したい IAM ロールの ARN"
},
"Action": [
"s3:ListBucket",
"s3:GetObject",
"s3:PutObject",
"s3:DeleteObject",
"s3:GetObjectTagging",
"s3:PutObjectTagging"
],
"Resource": [
"arn:aws:s3:::アクセスを許可するバケット名",
"arn:aws:s3:::アクセスを許可するバケット名/*"
]
}
]
}
別の AWS アカウントのリソースからのアクセス許可
バケットポリシーに設定できる IAM ロールは、同じ AWS アカウントの IAM ロールだけでなく、別の AWS アカウントの IAM ロールを設定することもできます。
よって、別の AWS アカウントから S3 バケットへアクセスを許可する方法は、主に次の 2 通りとなります。
- バケットポリシーに、アクセスを許可したい別の AWS アカウントの IAM ロールを直接指定する方法
- バケットポリシーに許可した IAM ロールに対し、別の AWS アカウントの IAM ロールから Assume Role する方法
後者の方法は Assume Role が必要になるため、クライアントは STS にアクセスできる必要があります。ガバメントクラウドで自治体基幹業務システムを運用する場合は、インターネット接続できない閉域の環境となるため、STS へアクセスするために VPC エンドポイントを作成する必要があることに注意しましょう。
IAM Identity Center ユーザーから個人情報を含む S3 バケットにはアクセスできない
マネジメントコンソールへのアクセスで確認した IAM Identity Center ユーザーの認証は、外部 IdP である GCAS へのアクセスにインターネット接続が必要です。
IAM Identity Center ユーザーのクレデンシャルを取得できるのはインターネット接続環境に限られてしまうため、個人情報を含む S3 バケットを IAM Identity Center で認証した AWS CLI やマネジメントコンソールで扱う操作はできないことに注意してください。
オンプレミスや別の CSP 環境から S3 バケットへアクセスする
ガバメントクラウドでは、オンプレミスや別の CSP 環境から個人情報を含む S3 バケットへアクセスする時も、認証認可が必要になります。
しかし、個人情報を含む S3 バケットへアクセスできるオンプレミスや別の CSP 環境は、インターネット接続がない閉域の環境となるため、閉域で完結する認証認可の仕組みを考える必要があります。
閉域で完結して S3 バケットへアクセスできる一時クレデンシャルを取得する方法
閉域で完結する必要があるので、S3 バケットへのアクセスに IAM Identity Center ユーザーの認証は使えません。
考えられる方法はいくつか存在します。
- プライベート認証局を構築して IAM Roles Anywhere を使う方法
- オンプレミスや別 CSP のリソースに Systems Manager Agent をインストールする方法
- SAML 認証に対応する認証認可サーバー（Keycloak など）を構築し、SAML レスポンスを使って STS にアクセスする方法
このうち、Keycloak などの SAML 認証に対応する認証認可サーバーを構築する方法は、デジタル庁が共通機能の標準仕様のリファレンス実装を公開しています。
しかし、これらの方法は AWS リソース以外にも構築しなければならないものが多く、構築と運用に相当な手間がかかります。特にオープンソースソフトウェアである Keycloak を採用する場合、エンタープライズサポートを受けるためには費用がかかります。
よって、自前でオンプレミスや別 CSP 環境向けに認証認可を構築することは可能ですが、保守運用に相応のコストがかかると考えられます。
また、これらの方法を採用する場合、オンプレミスや別 CSP 環境のクライアントは、S3 の API へアクセスできる方法を実装しなければなりません。
オンプレミスや別 CSP 環境からの S3 バケットへのアクセスには Transfer Family がおすすめ
同様にコストは要しますが、AWS のマネージドサービスだけでオンプレミスや別 CSP 環境からの S3 バケットへのアクセス方法と認証認可を一体で提供する方法があります。
それは、Transfer Family で S3 バケットと連携する SFTP サーバーを構築する方法です。
SFTP サーバーでクライアントのユーザーの公開鍵認証を行い、SFTP サーバーに設定した IAM ロールでアクセスできる S3 バケットのアクセス権を管理できます。
これにより、AWS のマネージドサービスで完結しつつ、クライアントは一般的な SFTP プロトコルで S3 バケットを操作することができます。
料金は東京リージョンだと USD 0.30 / 時間となっているため、一月あたり 220 ドル程度かかりますが、管理はユーザーの公開鍵認証用キーペア以外全て AWS 側の管理となるため、自前で認証認可を実装するよりもおすすめです。
具体的な Transfer Family での SFTP サーバー構築手順は、過去の記事にまとめていますのでよければ参考にしてください。
閉域での認証認可を理解する難しさ
ガバメントクラウドの AWS 環境で出てくる認証認可については、閉域ならではの難しさがあり、特に認証認可を構成する要素のネットワーク接続の知識も必要となることが難易度を上げています。
しかし、IAM の基本をしっかり押さえることができれば、あとはオンプレミスや自治体クラウドで培ってきたネットワークの知識と、新たに学ぶ AWS のネットワークの知識を組み合わせることで、ガバメントクラウドの認証認可を理解することができると思います。
むしろパブリッククラウドでインターネット接続のある環境しか扱ったことがない場合より、オンプレミスを知っている場合の方が、理解をしやすいと思っています。
今のところ、ガバメントクラウドを使う自治体情シスもある程度パブリッククラウドの仕組みを知っている必要がある状況ですが、この記事が理解の一助になれば幸いです。
また、ガバメントクラウドのような公共分野での AWS 活用に興味があれば、ぜひ Gov-JAWS に参加して、みんなで一緒に勉強しませんか？一人だと大変ですが、共有知でこの困難を乗り越えられるといいなと思っています。