ユーザー管理方法(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アカウントはデジタル庁にて発行する。
• 共同利用方式
  • AWSアカウントのルートユーザーはデジタル庁にて作成後、保有して管理する。ルートユーザーはデジタル庁のドメイン名のメールアドレスで作成する。
  • 各利用組織及びその開発運用委託業者がAWSアカウントへのアクセスに用いるGCASアカウントはデジタル庁にて発行する。

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

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

AWSにおけるユーザー認証・アクセス管理サービスとして、2011年にGAされたIAM(Identity Access Management)と2017年GAのIdCがある。

どちらもAWSのマネジメントコンソールやCLIを利用する際の認証機能とAWSのリソースに対するアクセス制御機能を合わせて提供する。ガバメントクラウドでは前者のサービスを利用して作成したIAMユーザーをシングルサインオン環境機能の展開前のAWS環境において利用中である。後者のIdCは一組織で複数のAWSアカウントを運用する際の認証及びアクセス制御を一元化するためにリリースされたサービスであり、ガバメントクラウドでは前述のとおり、シングルサインオン機能の実装に同サービスを用いる。

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

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

IAMユーザーとIAMポリシー

IAMユーザーはAWS IAM（Identity and Access Management）というサービスを利用することで作成できるユーザーである。IAM はAWS のサービスやリソースへのアクセスを安全に管理するために、認証／認可の仕組みを提供するサービスである。前述したGCASにおけるシングルサインオン機能の展開前のAWS環境では、IAMユーザーの運用が行われている。その際、ガバメントクラウドでは、IAMユーザーを管理者権限のユーザー(Adminユーザー)のみが作成できる。作成後は必ず多要素認証(MFA)を設定する（設定手順は末尾に記載）。シングルサインオン機能の展開後はIAMユーザーの作成、利用は原則禁止とする。

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

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

ガバメントクラウドでは、セキュリティの観点からリソース操作のために、必要なIAMポリシーが適用されたIAMロール（後述）の利用を前提としている。リソース参照作業のみの場合も、専用のIAMロールを作成する。そのため、IAMユーザーに参照権限を付与することは禁止とする。そのため、IAMユーザーには必要最小限の権限のみ付与する。具体的には以下のIAMポリシーのみ付与して管理者がIAMユーザーを作成する。

• IAMUserChangePassword (AWSマネージドポリシー)
• IAMSelfManageServiceSpecificCredentials (AWSマネージドポリシー)
• IAMReadOnlyAccess (AWSマネージドポリシー)
• IamUserMfaAndSwitchRolePolicy (ガバメントクラウドで作成したポリシー)

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

IAMロールの概要と使用

IAMロールはリソースの操作権限を記述したIAMポリシーを付与可能なAWS特有の機能であり、IAMユーザーはIAMロールの持つ権限を別の役割を演じるように利用可能である。IAMロール自体で永続的な認証情報を持つことはなく、IAMロール利用時は一時的な認証情報が発行される。一方、IAMユーザーは固定的な認証情報やCLIやプログラムでAPIを操作する際のアクセスキーを保有可能であり、認証情報の漏洩リスクが内包される。

ガバメントクラウドでは、前述の通りIAMユーザーに対してリソースの権限を付与するのではなく、必要な権限を持つIAMロールを利用することで、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アカウントではIAMロールを利用することになる。なお、シングルサインオンで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(順次廃止) GovCloudLgDataRegidency(順次展開)	AWSReservedSSO_AWSAdministratorAccess_ランダム文字列 AWSReservedSSO_GovCloudLgDataRegidency_ランダム文字列
  	管理者以外	SwitchOnlyRole	AWSReservedSSO_SwitchOnlyRole_ランダム文字列

　

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

　

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

　

• GovCloudLgDataRegidencyアクセス許可セット
  地方公共団体において、個人番号利用事務系に係るシステム環境では、インターネット接続系へのデータ持ち出しを禁止する目的で管理コンソールにおける本番業務データへのアクセスを制限する権限セット（アクセス許可セット）を本番環境に提供予定である。 例えば、インターネット経由で管理コンソールから直接のデータ参照や一部のサービスや機能の利用制限を予定している。
  具体的には今後、管理者向けに提供しているアクセス許可セットの切り替えを予定している。 なお、「GovCloudLgDataRegidency」の強制適用については当面予定をしておらず、実施する際は事前の周知を行う。
  • 制限の特にないアクセス許可セット名: AWSAdministratorAccess(本番環境は廃止予定)
  • 制限が施されたアクセス許可セット名: GovCloudLgDataRegidency(順次追加予定)
    これらは本番環境のみの制限であり、本番環境以外の環境においては、上記両方の権限(アクセス許可セット)が利用し続けられる。「地方SaaS」の本番環境においても同様である。
  • 制限されるサービスとActionは、アプリケーション内のデータを持ち出し可能となっているものを基本的に対象としている。 詳細は後述のJSONファイルを直接参照すること。
  • これらの制限が及んでいなかったとしても、総務省ガイドラインなどで禁止されているようなデータの参照・持ち出しが許可されているわけではない。

なお、一部の環境に試験的に提供していた「GovCloudLgDataRegidency」のアクセス許可セットは令和6年7月より提供を中断する。同アクセス許可セットの制限内容の利用を希望する組織向けに、制限内容を記述したJSONファイルを提供する（GCASアカウントを取得の上、GCASガイド（メンバー専用ページ）で公開されているガバメントクラウドテンプレート/ポリシー（メンバー専用ページ→ガバメントクラウドテンプレート/ポリシー→ガバメントクラウドテンプレート/ポリシーのダウンロードページ）を参照すること）。IAMロール等へ同ファイルの内容を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

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

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

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

（移行措置）IAMユーザーの運用

本項はガバメントクラウドにおけるGCASのシングルサインオン機能の利用前の環境を想定し、移行措置として記載する。なお、シングルサインオン機能利用開始後は、IAMユーザーは原則禁止となる。

IAMユーザーの設定

ガバメントクラウド(AWS)では、通常運用では発行されたIAMユーザーでログインすることを想定している。また、セキュリティの観点より、IAMユーザーのMFA(多要素)認証、及び必要最小限の権限を付与し、スイッチロールにて必要権限のIAMロールを使用することを想定している。AWSリソース参照作業のみの場合も、専用のIAMロールを作成して、IAMユーザーからスイッチする。なお、IAMユーザーにリソースへの参照権限を付与することは不可である。

• 管理者権限ユーザー（Adminユーザー）が、運用担当者1人に対して1つのIAMユーザーを作成する。なお、IAMユーザーは管理者権限のユーザーのみが作成できる。
  • 運用IAMユーザーの作成には、次の作業が必要である。
    • 運用担当者ごとのIAMユーザーの作成 (管理者権限ユーザーの作業)
    • 必要な権限のIAMロールを作成 (管理者権限ユーザーの作業)
    • IAMユーザーにMFAを登録する(各運用担当者の作業)
    • IAMユーザーからIAMロールにスイッチロールする(各運用担当者の作業)
  • IAMユーザーにアタッチできるIAMポリシーは、以下の4つである。
    • IAMUserChangePassword (マネージドポリシー)
    • IAMSelfManageServiceSpecificCredentials (マネージドポリシー)
    • IAMReadOnlyAccess (マネージドポリシー)
    • IamUserMfaAndSwitchRolePolicy (ガバメントクラウドで作成したポリシー)

IAMユーザーの作成

IAMユーザー作成手順

• ①(管理権限ユーザー) IAMロールは権限を使用できるユーザーを限定するため信頼関係を以下のように記載
  
• ②(管理権限ユーザー) 運用担当者に、AWSアカウントIDと作成したIAMユーザーとそのパスワード、および運用で利用するIAMロールとIAMロールへスイッチするURL（下画面で取得可能）を伝える
  
• ③(利用ユーザー) 運用担当者が、管理者権限ユーザーから別途受け取ったAWSアカウントIDとIAMユーザーID、パスワードでAWSマネジメントコンソールにログインし、 IAMのダッシュボードから自分でMFAを設定
  
  ※AWSマネジメントコンソールのURL　https://console.aws.amazon.com/open_in_newOpens in new tab
• ④(利用ユーザー) 以下の画面が表示されるのでMFAを設定する。なお、設定にあたり デバイス名はIAMユーザー名と同一にすること。 今回は仮想MFAデバイス(ソフトウェアMFA)の設定方法を紹介する。
  
• ⑤(利用ユーザー) 仮想MFAデバイス用のソフトウェアを用意し、「QRコードの表示」をクリックしQRコードを表示後、各のソフトウェアに応じてMFAを設定する
  設定後、連続する2回分のMFAコードが要求されるので入力する
  
• ⑦(利用ユーザー) 仮運用担当者が、MFA設定後一度ログアウトし、再度IAMユーザーにログインしてMFA認証を行う（一度ログアウトしない場合MFAが有効化されていないと判断され後続の作業が実施できないため注意）
• 管理者権限ユーザーから受け取ったスイッチロール用のURLにアクセスし、割り振られたIAMロールにスイッチしAWSコンソールを使用する
  https://signin.aws.amazon.com/switchrole?roleName=該当のロール名&account=アカウントID
  

[AWSドキュメント：AWS アカウントでの IAM ユーザーの作成]
https://docs.aws.amazon.com/ja_jp/IAM/latest/UserGuide/id_users_create.htmlopen_in_newOpens in new tab

IAMユーザー管理運用方法

IAMユーザーの利用方法

ガバメントクラウド(AWS)では、必要最小限の権限を付与し、スイッチロールにて必要権限のIAMロールを使用すること。

[AWSドキュメント：ロールの切り替え(コンソール)]
https://docs.aws.amazon.com/ja_jp/IAM/latest/UserGuide/id_roles_use_switch-role-console.htmlopen_in_newOpens in new tab

[AWSドキュメント：IAMロール (AWS CLI) の切り替え]
https://docs.aws.amazon.com/ja_jp/IAM/latest/UserGuide/id_roles_use_switch-role-cli.htmlopen_in_newOpens in new tab
　

IAMユーザーの棚卸

セキュリティの確保のため、定期的にIAMユーザーの棚卸を行ない、ユーザー,ユーザーグループ,ロールの適格性を確認する。
アクセスキーは原則利用禁止であるが、システム構成を十分に検討した結果、SaaS等の利用におけるIAMロール使用時にアクセスキーを使用せざるを得ないとは判断した場合には、ガバメントクラウドチームで内容を審査するため個別に連絡すること。
審査の結果、妥当と判断した場合には、SCPの緩和措置を講じることでIAMユーザーのアクセスキーID、シークレットアクセスキーを用いた認証運用が可能となる。なお、アクセスキーローテーションの確認及び有効期限設定の確認を行なう。　　

[AWSドキュメント：IAM ユーザーの管理/IAMユーザーの一覧表示]
https://docs.aws.amazon.com/ja_jp/IAM/latest/UserGuide/id_users_manage.html#id_users_manage_listopen_in_newOpens in new tab

[AWSドキュメント：AWS アカウントの認証情報レポートの取得]
https://docs.aws.amazon.com/ja_jp/IAM/latest/UserGuide/id_credentials_getting-report.htmlopen_in_newOpens in new tab

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

[AWS アクセスキーを管理するためのベストプラクティス]
https://docs.aws.amazon.com/ja_jp/general/latest/gr/aws-access-keys-best-practices.htmlopen_in_newOpens in new tab

[AWSドキュメント：AWS access-keys-rotated]
https://docs.aws.amazon.com/ja_jp/config/latest/developerguide/access-keys-rotated.htmlopen_in_newOpens in new tab

IAMグループの設定

ガバメントクラウドではIAMユーザーの権限を、グループ単位で制御・管理することが推奨される。
IAMグループにアタッチできるIAMポリシーは、以下の4つである。

• IAMUserChangePassword (マネージドポリシー)
• IAMSelfManageServiceSpecificCredentials (マネージドポリシー)
• IAMReadOnlyAccess (マネージドポリシー)
• IamUserMfaAndSwitchRolePolicy (ガバメントクラウドで作成したポリシー)

[AWSドキュメント：IAMユーザーグループの作成]
https://docs.aws.amazon.com/ja_jp/IAM/latest/UserGuide/id_groups_create.htmlopen_in_newOpens in new tab

[AWSドキュメント：IAM グループへのユーザーの追加と削除]
https://docs.aws.amazon.com/ja_jp/IAM/latest/UserGuide/id_groups_manage_add-remove-users.htmlopen_in_newOpens in new tab

IAMポリシーの設定

ガバメントクラウド(AWS)では、IAMポリシーを作成し、アクセス管理を行なう。
IAMポリシーにはポリシーがスタンドアロンとして存在する「管理ポリシー」とIAMユーザー等の中に埋め込まれる「インラインポリシー」があり、ガバメントクラウドでは管理ポリシーの使用が推奨される。
IAMユーザー及びIAMグループに割り当てができるポリシーを以下に示す。

• IAMUserChangePassword (マネージドポリシー)
• IAMSelfManageServiceSpecificCredentials (マネージドポリシー)
• IAMReadOnlyAccess (マネージドポリシー)
• IamUserMfaAndSwitchRolePolicy (ガバメントクラウドで作成したポリシー)

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

Adminユーザー権限について

Adminユーザーでのみ実行可能なサービス/アクション

Adminユーザーのみで実行可能なサービス/アクションについて以下に示す。IAMユーザーでは実行することができないため、以下の作業を行う必要がある開発事業者は、Adminユーザーの払い出しを受ける必要がある。
なお、詳細については「自動適用テンプレート」を参照すること。

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

改訂履歴