Change Managerによる変更管理と本番アクセス統制　④Change Managerセットアップ編

Change Managerとは
Change Managerでどのように変更管理と本番アクセス統制をするか
Change Managerのセットアップ
組織の管理アカウントでChange Managerをセットアップ
まとめ
「Change Managerによる変更管理と本番アクセス統制」シリーズ全編はこちら

こんにちは、クラウドセキュリティアーキテクトの大島悠司です。

7編にわたって、「Change Managerによる変更管理と本番アクセス統制」について紹介しています。

前回の「③Session Managerログイン&ロギング編」では、エビデンス取得のためのSSHを使わないインスタンス接続やロギングについて紹介しました。
今回の「④Change Managerセットアップ編」では、Change Managerのセットアップ方法と、本番アクセス統制のために追加で必要な設定やハマりやすいポイントを紹介します。

Change Managerとは

「③ Session Managerログイン&ロギング編」で紹介したSession Managerは、AWS Systems Managerの1機能でした。
Change Managerも同様にAWS Systems Managerの1機能であり、アプリやインフラの変更管理を提供するものです。

docs.aws.amazon.com

Change Managerでどのように変更管理と本番アクセス統制をするか

「②マルチアカウント&IAM設計編」で紹介したIAM設計を活用します。
Jumpアカウントに集約したIAMユーザをグループに分け、それぞれの役割に応じたアカウント/ロールにスイッチできるようにする方式でした。

今回は、Jumpアカウントに本番アクセス用グループ「ProdShainWorkGroup」と「ProdPartnerWorkGroup」を新たに追加します。
この本番アクセス用グループには、本番アカウントへスイッチできる権限が既に割り当てられているため、当該グループにIAMユーザを追加/離脱することでスイッチロールの可否を制御することができます。

本番アクセス用グループへの追加は、作業者がChange Managerでリクエスト作成し、承認者がリクエスト承認することで自動的に実行されます。
さらに、どのIAMユーザがどのグループにいつまで参加し続けるのかを管理するために、グループ参加と同時にIAMユーザにTTLを記したタグも付与します。

作業者は本番アカウントへスイッチロールし、インスタンスでの作業は「③ Session Managerログイン&ロギング編」で紹介した方法で作業をし、コマンドログは作業証跡として自動的に保存されます。

再掲になりますが、以下が今回実現したいことの全体像です。

Change Managerのセットアップ

それでは実際に、Change Managerをセットアップしていきます。
手順が長く複雑ですが、順を追って説明していきます。

組織の管理アカウントでChange Managerをセットアップ

組織の管理アカウントでSystems Managerの「高速セットアップ（Quick Setup）」から、Change Managerの「Create」を押下します。

委任管理者アカウント（Delegated administrator account）にはJumpアカウントIDを入力し、ジョブ機能（Job functions）に任意の名前を付けて、実行権限（Permissions）は「Administrator permissions」を選択します。

※簡易のため、「Administrator permission」にしているが、実運用では要件に合うように「Custom permissions」を設定する方が望ましい。

注意
Change Managerは組織のメンバーアカウントに対する変更管理を前提としています。
そのため、委任管理アカウントはOrganizationの管理アカウントを指定できません。

Change Managerにより変更が及ぶアカウントの範囲をTargetsで指定します。今回は「Entire organization（組織全体）」を選択します。

※簡易のため「Entire organization（組織全体）」を選択しているが、実運用では「Custom（カスタム）」でOUごとに選択するほうが望ましい。

セットアップが完了しました。画面下部の詳細には、Change Managerで変更が及ぶアカウントが表示されています。

※アカウント数は環境により異なります。

作成されたロールの確認

委任管理アカウントには「AWS-QuickSetup-SSMChangeMgr-<ジョブ機能名>AdminRole」ロールが作成されており、変更が及ぶアカウントの「AWS-QuickSetup-SSMChangeMgr-<ジョブ機能名>InvocationRole」にAssumeRoleできるようになっています。

一方、変更管理対象のアカウントには「AWS-QuickSetup-SSMChangeMgr-<ジョブ機能名>InvocationRole」ロールが作成されおり、権限はジョブ機能で指定したAdministrator権限になっています。

このロールは信頼関係として委任管理アカウントが設定されています。

委任管理アカウントでChange Managerの設定

委任管理アカウントのChange Managerから設定を行います。

ユーザーのID管理としてIAMとSSOを選択できますが、今回はJumpアカウント方式のためIAMを選択します。
変更管理ではあらかじめ登録されている変更テンプレートというものを使用しますが、その変更テンプレートに追加や修正があったときは他のユーザからの承認を得る必要があります。

テンプレートレビューアとしてJump_AdminRoleを選択し、その通知先を選択します。
レビューアはユーザ/グループ/ロールを選択できますが、ここではJumpアカウントのAdminロールを指定します。

通知先SNSは、Jump_AdminRoleにスイッチ可能なIAMユーザの連絡先を、サブスクリプションとして登録しているSNSトピックを選択するとよいでしょう。

Change Managerを使用するための権限を設定

権限周りは公式ドキュメントも併せてご確認ください。

docs.aws.amazon.com

リクエスト作成に必要な権限

作業者がChange Managerでリクエストを作成する際には、JumpアカウントのIAMユーザに対していくつか権限が必要です。
まず、作業者が承認者を選択するためにIAM閲覧の権限が必要なので、ここでは「ReadOnlyAccess」を付与します。

注意
リクエストを作成しようとするIAMユーザにIAM閲覧ポリシーがないと、ユーザ情報のロードができないため承認者を選択できず、起票が不可になる。

次に、Change Managerのリクエスト作成時にどのロール権限で実行するかを選択するのですが、「AWS-QuickSetup-SSMChangeMgr-<ジョブ機能名>AdminRole」ロールを使う場合には、そのロールをユーザが使えるようにPassRole権限を付与する必要があります。

注意
IAMユーザに対して、Change Managerリクエスト作成時に指定するロールを使えるようにPassRole権限を与えないと、リクエスト作成時にエラーになる。

最後に、Change Managerを承認、実行、キャンセルするために以下の権限が必要です。

ssm:StartChangeRequestExecution 承認に必要
ssm:SendAutomationSignal　承認してから実行に移すために必要
ssm:StopAutomationExecution　キャンセルに必要

最終的に、「ReadOnlyAccess」に加えて以下のポリシーがあれば、起票者/承認者に最低限必要な権限は揃います。

{
    "Version": "2012-10-17",
    "Statement": [
        {
            "Action": [
                "iam:PassRole"
            ],
            "Resource": [
                "arn:aws:iam::<accountID>:role/AWS-QuickSetup-SSMChangeMgr-MyAWSAdminAdminRole"
            ],
            "Effect": "Allow"
        }
    ]
}

{
    "Version": "2012-10-17",
    "Statement": [
        {
            "Action": [
                "ssm:StartChangeRequestExecution"
            ],
            "Resource": [
                "arn:aws:ssm:*:<accountID>:automation-definition/*:*"
            ],
            "Effect": "Allow",
            "Sid": "StartChangeRequestExecution"
        },
        {
            "Action": [
                "ssm:SendAutomationSignal"
            ],
            "Resource": "*",
            "Effect": "Allow",
            "Sid": "SendAutomationSignal"
        },
        {
            "Action": [
                "ssm:StopAutomationExecution"
            ],
            "Resource": "*",
            "Effect": "Allow",
            "Sid": "StopAutomationExecution"
        }
    ]
}

自身のアカウントに変更をかける用の権限

Change Managerは、委任管理者アカウントとは別のメンバーアカウントに対して変更をかけることを想定しています。

これにより、メンバーアカウントに作成された「AWS-QuickSetup-SSMChangeMgr-<ジョブ機能名>InvocationRole」は委任管理者アカウントであるJumpアカウントには作られません。

そのため、自身のアカウントに対する変更するために「AWS-QuickSetup-SSMChangeMgr-（ジョブ機能の名前）AdminRole」を指定してリクエストを作成しても、権限がなくエラーになってしまいます。

対応策として、Jumpアカウントの「AWS-QuickSetup-SSMChangeMgr-<ジョブ機能名>AdminRole」に、その他のメンバーアカウントの「AWS-QuickSetup-SSMChangeMgr-<ジョブ機能名>InvocationRole」と同等のポリシーを追加で付与します。
今回はAdministrator権限を想定しているので、以下のインラインポリシーを追加します。