ユーザー管理方法(AWS編)

ガバメントクラウド利用組織がセキュリティや運用の設計をする際に必要となる、AWSユーザー管理のベストプラクティスや手法を理解するための文書である。

ユーザー管理の全体像

ガバメントクラウドのAWS環境では、ガバメントクラウド利用組織からの利用申請の情報に基づき、ガバメントクラウド管理組織より必要な環境数分のAWSアカウントが払い出される。AWSアカウントはAWS環境におけるリソース管理やコスト管理等の区分になり、AWSアカウント内にシステム環境を構築することになる。AWSアカウントにおいて最も強力な権限を持ち、システムの所有者として位置付けられるルートユーザーはAWSアカウントとともにガバメントクラウド管理組織が作成する。ルートユーザーは各アカウントに一つ作成され、IDとしてメールアドレスが用いられる。

ユーザーアカウントは、GCASアカウントによる各CSP環境へのシングルサインオン機能が令和6年度より展開されているため、GCASアカウント以外のユーザーアカウントを利用組織で作成する必要はない。ガバメントクラウド管理組織が払い出したGCASアカウントによるAWSアカウントへのアクセスが可能になる。なお、GCASアカウントとの連携では後述するAWSIAMIdentityCenter（以下IdC）を用いている。

以下に、国の行政機関および地方公共団体におけるユーザー管理について補足する。

国の行政機関

国の行政機関が利用するAWS環境では、前述のルートユーザーをデジタル庁にて保有し、管理する。各利用組織及びその開発運用委託業者がAWSアカウントへのアクセスに用いるGCASアカウントはガバメントクラウド管理組織にて発行する。

図01-1-A:ユーザー管理の全体像(国の行政機関)

地方公共団体

地方公共団体が利用するAWS環境は、単独利用方式と共同利用方式いずれもユーザーの利用形態は同じとなる。
AWSアカウントのルートユーザーはデジタル庁にて作成後、保有して管理する。
各利用組織及びその開発運用委託業者がAWSアカウントへのアクセスに用いるGCASアカウントはデジタル庁にて発行する。

図01-2-B:ユーザー管理の全体像(地方公共団体)

AWS環境における認証とアクセス権管理

AWSにおけるユーザー認証・アクセス管理サービスとしてIdCがあり、一組織で複数のAWSアカウントを運用する際の認証及びアクセス制御を一元化するためにリリースされたサービスとして使われている。ガバメントクラウドでは前述のとおり、シングルサインオン機能の実装に同サービスを用いる。

これにより、ガバメントクラウドで提供するAWS環境では、利用者はGCASアカウントと同期されたIdCのユーザーアカウントを利用して各AWSアカウントへの認証およびアクセスが制御されることになる。IdCはデジタル庁が管理するAWSアカウント内に構成されている。

図01-3アカウントによるAWS環境へのシングルサインオンイメージ

IAMユーザーとIAMポリシー

IAMユーザーはAWS IAM（Identity and Access Management）というサービスを利用することで作成できるユーザーである。IAM はAWS のサービスやリソースへのアクセスを安全に管理するために、認証／認可の仕組みを提供するサービスである。ガバメントクラウドではGCASにおけるシングルサインオン機能の展開後はIAMユーザーの作成ができないようシステム的に制御し、利用を原則禁止している。

IAMではIAMユーザーや後述するIAMロールにIAMポリシーを設定し、AWSリソースへのアクセス許可と権限を設定できる。IAMポリシーとは、ユーザーなどのアクセス主体が実行できる「アクション（操作）、操作対象リソース、条件」を制御するJSON 形式のドキュメントを指す。

図01-4ポリシーによるアクセス権の付与

ガバメントクラウドでは、セキュリティの観点からリソース操作のために、必要なIAMポリシーが適用されたIAMロール（後述）の利用を前提としている。リソース参照作業のみの場合も、専用のIAMロールを作成する。

[AWSドキュメント：IAMでのポリシーとアクセス許可]
https://docs.aws.amazon.com/ja_jp/IAM/latest/UserGuide/access_policies.htmlopen_in_newOpens in new tab

IAMロールの概要と使用

IAMロールはリソースの操作権限を記述したIAMポリシーを付与可能なAWS特有の機能であり、後述するIdCユーザーはIAMロールの持つ権限を別の役割を演じるように利用可能である。IAMロール自体で永続的な認証情報を持つことはなく、IAMロール利用時は一時的な認証情報が発行される。

なお、IAMロールへの切り替え（スイッチロール）を実現するAPIはAssumeRoleであるため、AssumeRoleとも表現する。

図01-5ロールの利用イメージ

また、AssumeRoleは別のAWSアカウントのIAMロールにも利用可能である。AというAWSアカウントに存在するリソースにアクセスしたい作業者がいるが、作業者はAにはIAMユーザーを持っておらず、Bという別のAWSアカウントにIAMユーザーを持っている、というケースがあるとする。この場合、Aに作業者用のIAMユーザーを作成するのではなく、IAMロールを作成し、BのIAMユーザーにAssumeRoleさせることで、新規にIAMユーザーを作成する必要がなくなり、認証情報の漏洩リスクを軽減することができる。

[AWSドキュメント：AssumeRole]
https://docs.aws.amazon.com/ja_jp/STS/latest/APIReference/API_AssumeRole.htmlopen_in_newOpens in new tab

IdCのユーザーとデフォルトで提供されるIAMロール

GCASのシングルサインオン機能が展開された各利用組織はGCASアカウントによる認証後、IdCが提供するポータル画面にアクセスしてログイン先を選択する（詳細はクラウドサービスの操作方法(AWS編)参照）。その際、GCASアカウントと同期されたIdCのユーザーで各AWSアカウントにログインすることになる。なお、シングルサインオンでAWSアカウントへログインするには、GCAS上でCSPユーザー登録が必要になる。CSPユーザー登録の具体的な手順は、GCASシステム情報登録操作説明(国の行政機関向け)の「GCASアカウント取得後の諸手続きについて」、GCASシステム情報登録操作説明(地方公共団体向け)の「GCASアカウント取得後の諸手続きについて」に含まれる各資料の「CSPユーザ登録」のページを参照すること。以下にIdCにおけるユーザーとアクセス管理、IAMロールについて説明する。

• IdCにおけるユーザー
  IdCではAWSアカウントへのアクセスのためにIdC内でユーザー情報を保有しIdentity Provider(IdP)として運用する形態と外部IdPとして運用する形態を選択可能である。ガバメントクラウドではGCASで構成されるCloud Identityを外部IdPとして利用する。この利用形態において、GCASアカウントのメールアドレスをIdCのユーザー名として利用している。

• IdCにおける各AWSアカウントへのアクセス管理
  IdCは各AWSアカウントへのアクセスを以下の要素を組み合わせて管理する。各AWSアカウントへのアクセスは、IdCのポータル上でAWSアカウントとアクセス許可セットを選択して行う。

  • アクセス先となるAWSアカウント
    CSPユーザー登録で登録する該当ユーザーのアクセス可能なAWSアカウント情報を指す。
  • アクセス許可セット
    CSPユーザー登録で登録する該当ユーザーの権限種別に基づき割り当てる、一連のアクセス権を指す。
  • ユーザーまたはグループ
    AWSアカウントへのアクセス元となるIdCのユーザーまたはグループを指す。
    
    図01-6におけるアクセス管理

• アクセス許可セットの提供
  令和6年度現在、ガバメントクラウドでは以下のアクセス許可セットを提供している。ガバメントクラウドでは管理者と管理者以外でアクセス許可セットの割り当てが異なる。管理者はAWS上のリソース操作に対する強い権限を持つAWSAdmininistratorAccessのアクセス許可セット、管理者以外はスイッチロール（後述）だけができるアクセス許可セットが割り当てられる。 CSPユーザー登録におけるユーザーの権限についてはGCASガイドの「ガバメントクラウド利用概要(AWS編)」を参照すること。 「管理者」を選択するとCSPユーザーに管理者ユーザー相当の権限「AWSAdministratorAccess」が割り当てられ、「メンバー」を選択すると管理者以外の権限「SwitchOnlyRole」が割り当てられる。
  また、管理者権限ユーザーが侵害される可能性を減らすため、本番環境の管理者権限ユーザーの人数は3名までを推奨する。
  　

  表01-1 ガバメントクラウドで提供するアクセス許可セット

  組織種別	権限種別	提供するアクセス許可セット	各AWSアカウントに作成されるIAMロール
  国の行政機関	管理者	AWSAdministratorAccess	AWSReservedSSO_AWSAdministratorAccess_ランダム文字列
  	管理者以外	SwitchOnlyRole	AWSReservedSSO_SwitchOnlyRole_ランダム文字列
  地方公共団体	管理者	AWSAdministratorAccess	AWSReservedSSO_AWSAdministratorAccess_ランダム文字列
  	管理者以外	SwitchOnlyRole	AWSReservedSSO_SwitchOnlyRole_ランダム文字列

　

• AWSAdministratorAccess許可セット
  AWSAdministratorAccess許可セットのみで実行可能なサービス/アクションについて以下に示す。なお、詳細についてはメンバー専用ページ内の「自動適用テンプレート」を参照すること。

　

※Adminユーザーはバージニア北部でS3の全操作を実行可能だが、 IAMユーザーも読み取り権限などの一部操作を実行可能。

　

• 管理コンソールにおける本番業務データへのアクセスを制限するIAMポリシーサンプルの提供

  地方公共団体の個人番号利用事務系に係るシステム環境からインターネット接続系へのデータ持ち出しを制御する手法として、ガバメントクラウド運用管理組織より、AWSマネジメントコンソールを介した本番業務データへのアクセスを制限するIAMポリシーサンプルを提供している。 例えば、インターネット経由でAWSマネジメントコンソールからS3バケット内のデータ参照など一部のサービスや機能の利用制限を含めている。
  これらの制限内容を記述したJSONファイルはGCASアカウントを取得の上、GCASガイド（メンバー専用ページ）で公開されている「ガバメントクラウドテンプレート/ポリシー」ページ（メンバー専用ページ→ガバメントクラウドテンプレート/ポリシー→ガバメントクラウドテンプレート/ポリシーのダウンロードページ→GovCloudLgDataRegidencyアクセス許可セットJSONファイル）へアクセスし取得可能である。このJSONファイルの内容を利用システム側で作成したIAMロールへIAMポリシーとして適用することを想定している。インターネット接続系からのデータの参照‧持ち出しを制限し、適切な運用が行われていることを効率的に確認するために上記ポリシーを活用することで、ログの分析等により運用の適切性を人的に確認する範囲を極小化することを想定している。
  なお、上記ポリシーを含む形態で一部の環境に試験的に提供していた「GovCloudLgDataRegidency」のアクセス許可セットは令和6年7月より提供を中断している。これらの提供が及んでいなかったとしても、総務省「地方公共団体における情報セキュリティポリシーに関するガイドライン」などで禁止されているような異なるネットワーク系統の相互のデータ参照‧持ち出しが許可されているわけではない。上記のIAMポリシーサンプルの活用検討を推奨する。

• 各AWSアカウントログイン後に利用されるIAMロール
  AWSリソースへのアクセス権を持つ一方で永続的な認証情報を持たないIAMロールは、AWS環境において頻繁に利用される。例えばIdCのユーザーやEC2などのAWSリソースはIAMロールを割り当てられ、IAMロールの持つアクセス権でリソースを操作可能である。
  デジタル庁における前述のアクセス管理の設定後、アクセス先のAWSアカウントには自動的にIAMロールが生成される。このIAMロールは、AWSReservedSSO_(アクセス許可セット名)_(英字小文字と数字の組み合わせのランダムな文字列)という命名規則で作成される。IdCユーザーはアクセス許可セットを選択してアクセス先へのログイン後、同許可セットに対応づけられたIAMロールが自動的に割り当てられ利用することになる。
  [AWSユーザーガイド：IAM Identity Center とは何ですか?]
  https://docs.aws.amazon.com/ja_jp/singlesignon/latest/userguide/what-is.htmlopen_in_newOpens in new tab

スイッチロールと利用システム側によるIAMロールの作成

前述の通り、各IdCユーザーはAWSアカウントにアクセスした時点でIAMロールを利用している。管理者以外のユーザーはSwitchOnlyRoleのアクセス許可セットが割り当てられ、「AWSReservedSSO_SwitchOnlyRole_ランダム文字列」という名称のIAMロールを利用する。このIAMロールはスイッチロールのみ可能なアクセス権を保有する。

図01-7:スイッチロールの利用イメージ

スイッチロールとは、最初のIAMロールから別のIAMロールを利用する操作を意味しており、ポリシー設定に基づいてAWSアカウント内や他のAWSアカウントのIAMロールに対して行うことができる。

このスイッチロールにより、利用システム側で自らの開発や運用に合わせて作成したIAMロールを利用可能になる。IAMロールの作成は管理者による作業を想定している。利用システム側で必要となる権限とロールを整理し、必要な種類と数のIAMロールを作成する。その際、IAMロールには各AWSリソースの操作に必要なアクセス権を最小権限の原則に従って付与する必要がある。

なお、本方式の採用はガバメントクラウドの管理上、利用システム側に対してIdCの管理コンソールを開放し自由なアクセス権の設定権限を付与できない背景による。

スイッチロールの操作は次の手順に従う。AWSマネジメントコンソールの右上にある操作メニューから「ロールの切り替え」をクリックする（図01-8）。

図01-8:スイッチロールの操作開始箇所

続いて遷移する画面（図01-9）で「アカウント」（AWSアカウントID）、ロール（利用システム側で作成したIAMロール名）を入力して「ロールの切り替え」をクリックする。

図01-9:ロールの切り替え

作成したIAMロールの保護

利用システム側で作成したIAMロールに対して、IdC経由で適用されているIAMロール（「AWSReservedSSO_SwitchOnlyRole_ランダム文字列」等）からスイッチロールするために信頼ポリシーを設定する必要がある。信頼ポリシーとはIAMロールが他の主体から利用される際の許可条件を指定するために用いられる。

このIAMロールにおける信頼ポリシーの設定は利用システム側の管理者による作業を想定している。

信頼ポリシーの設定では、第三者のAWSアカウントからのアクセスや、職務上操作権限が不要なユーザーからの該当IAMロールの意図せぬ使い回しを避けるため、IdCのユーザー名を個別に指定したアクセス制御を強く推奨する。

図01-10:スイッチロールできるIdCユーザーの指定イメージ

信頼ポリシーの例は以下の通り。

{
  "Version": "2012-10-17",
  "Statement": [
    {
      "Effect": "Allow",
      "Principal": {
        "AWS": "arn:aws:iam::(AWSAccountのID):role/aws-reserved/sso.amazonaws.com/ap-northeast-1/AWSReservedSSO_SwitchOnlyRole_(ランダム文字列)"
      },
      "Action": "sts:AssumeRole",
			"Condition": {
          "StringLike": {
              "aws:userid": [
								"*:(IdCのユーザー名)",
								"*:(IdCのユーザー名)"
							]
          }
      }
    }
  ]
}

この信頼ポリシーでは以下の内容を指定する必要がある。

• Principal句におけるアクセス元のAWSアカウントの指定
  IdC経由でアクセスしたAWSアカウント内のスイッチロールにするため、同AWSアカウントのIDとスイッチロール元のIAMロールを指定する。なお、Principal句において(AccountID)を記載する場合、そのAWSアカウント内の全てのIAMエンティティ(IAMユーザーやIAMロールを指す)からのスイッチロールが許可されるため、注意が必要である。また、この箇所にIdcのユーザー名を指定することはできない仕様のため、スイッチロール先のIAMロールの利用ユーザーを最小化するため、次のIdCのユーザー名を指定すること。
• IdCのユーザー名の指定
  Condition句にスイッチロール元のIAMロールのRoleId、IdCのユーザー名を指定する。IdCのユーザー名は、GCASアカウントのIDと同一であり、xxx@(lg)id.cloud.go.jpになる。ポリシー例でワイルドカードを用いている箇所にはロールIDを指定可能である。ただし、AWS CLIを利用して以下のコマンドで取得する必要があるため、運用の容易性を考慮しポリシー例ではワイルドカードを用いている。
  
  $ aws iam get-role --role-name ${AWSReservedSSO_SwitchOnlyRole_ランダム文字列}

IAMロールに割り当てるIAM許可ポリシー

IAM許可ポリシーとは「ユーザーまたはIAMロールが実行できるアクション（行動）、リソース、条件」を制御するJSON 形式のドキュメントである。IAMユーザーやIAMロールは作成しただけでは何もできないので、リソースを操作できるようにIAM許可ポリシーを作成してアタッチする必要がある。通常、IAMポリシーと略されることが多い。IAMポリシーは自分で作成するカスタマー管理ポリシーと、AWSが作成および管理するAWS管理ポリシーがある。AWS管理ポリシーはAWSサービスの機能拡張に合わせて自動更新される。特によく使われる権限のセットとして「AWSジョブ機能の管理ポリシー」がAWS から提供されている。ガバメントクラウド利用組織は、権限の最小化を念頭にIAMポリシーの設計を検討する。

詳細は「セキュリティ(AWS)-リソースへのアクセス制御open_in_newOpens in new tab」の内容を確認する。

[AWSユーザーガイド：AWSジョブ機能の 管理ポリシー]
https://docs.aws.amazon.com/ja_jp/IAM/latest/UserGuide/access_policies_job-functions.htmlopen_in_newOpens in new tab

アクセスキーの原則利用禁止

IAMユーザーの運用において、CLIやプログラムでAPIを操作する際の認証情報であるアクセスキーの発行機能がAWSより提供されている。ただし、アクセスキーがハードコーディングされたソースコードが流出することで、これまでに不正アクセスなどのセキュリティインシデントとして多数報道されてきた。そのため、ガバメントクラウドではアクセスキーを原則利用禁止とする。ただし、システム構成を十分に検討した結果、SaaS等の利用においてアクセスキーを使用せざるを得ないとは判断した場合には、ガバメントクラウド管理組織で内容を審査するため個別に連絡すること。審査の結果、妥当と判断した場合には、IAMユーザーのアクセスキー、シークレットアクセスキーを用いた認証運用が可能となる。

[AWSドキュメント：IAM ユーザーのアクセスキーの管理]
https://docs.aws.amazon.com/ja_jp/IAM/latest/UserGuide/id_credentials_access-keys.htmlopen_in_newOpens in new tab

改訂履歴