AWS Change Manager でセキュアに本番環境アクセス

はじめに

みなさんは本番環境へのアクセスをどのように管理していますか？
最小権限でのアクセス、ダブルチェックの徹底、アクセス履歴の記録、鍵付きセキュリティルームetc.

本番環境へのアクセスは非常に重要で、慎重な対応が求められます。そのため、各チームや組織で運用ルールが定められていると思います。

今回は、AWS Change Manager を活用して、よりセキュアな本番環境アクセスの仕組みを実装する方法についてご紹介します。

　
　
なお、この記事は 2024 Japan AWS Jr. Champions に選出されたメンバーによるブログリレーの一環として執筆しています。今週は私が担当します！アウトプットを通じて、皆さんの学びに少しでも貢献できれば幸いです。

1 . Change Manager について

そもそも Change Manager とは、というところから説明します。
Change Manager は AWS Systems Manager の機能の 1 つです。

最近のアップデートによりマネジメントコンソール上では「変更マネージャー」と表記されています。（2024/11 時点）

Change Manager の機能をわかりやすく 3 行で表してみました。
　

1. "申請者"が事前にテンプレート化された変更処理をリクエスト
2. "承認者"がリクエストを承認
3. 承認後、変更処理が実行される

　
上述の通り、変更管理ツールである Change Manager は、「誰が」「なぜ」「どのように」変更を依頼し、承認したのかというプロセス全体を追跡・管理し、より安全性のある業務フローを実装できます。

　
　
もう少し理解を深めるため、基本的な処理の流れを図でみていきます。

テンプレートは AWS リソースやインフラ変更のプロセスを標準化するための構成済みフレームワークを指します。承認者もテンプレートごとに設定できるため、テンプレートを利用することで、変更手順や承認フローを一貫して適用することが可能となります。

また、テンプレートには Runbook（SSM Automation）が紐づいており、この Runbook に変更処理を記述します。Runbook には 自作あるいは AWS によって用意されたものが利用可能です。

今回、本番環境アクセス統制にこの Change Manager を使用していくということで、下記
構成を目指します。

2. 本番環境アクセス構成図

• 本番環境に用意された IAM ロールへ踏み台環境からスイッチロールでアクセスする
• Change Manager リクエスト承認後、申請者 IAM ユーザーにアクセス権限（IAM ポリシー）を付与する変更処理
• 変更リクエストの際に、下記パラメータを指定できるようテンプレートを構成する
  　　- アクセス先アカウント ID
  　　- アクセス可能時刻
• 承認者によってリクエストが承認されると申請者の指定したアクセス先にアクセスできる

　

スイッチロールのセッション継続時間は IAM ロール側で設定する値に準じます。
リクエストの際に指定する時間は AssumeRole API の実行（スイッチロールの操作自体）を制限します。

3. 作成手順

Change Managerテンプレートと テンプレートに紐付ける Runbook を作成します。
先に Runbook を作成し、その後テンプレートを作成します。

3.1. Runbook 作成
3.2. Change Manager テンプレート作成

3.1. Runbook 作成

SSM ＞ [ドキュメント] ＞ [ドキュメントの作成] ＞ [オートメーション] より作成していきます。

　
　
ビジュアルエディタで作成可能ですが、今回は YAML コードで作成します。

qiita.rb

schemaVersion: '0.3'
assumeRole: arn:aws:iam::"踏み台アカウントID":role/"実行権限ロール"
parameters:
  IAMUserName:
    type: String
    description: アクセスする IAM ユーザー名
  AWSAccountId:
    type: String
    description: 本番環境 AWS アカウント ID
  StartTime:
    type: String
    description: アクセス開始時刻 ex) 2024-11-26T18:00:00Z
    allowedPattern: ^[0-9]{4}-[0-9]{2}-[0-9]{2}T[0-9]{2}:[0-9]{2}:[0-9]{2}Z
  EndTime:
    type: String
    description: アクセス終了時刻 ex) 2024-11-26T19:00:00Z
    allowedPattern: ^[0-9]{4}-[0-9]{2}-[0-9]{2}T[0-9]{2}:[0-9]{2}:[0-9]{2}Z$
mainSteps:
  - name: PutInlinepolicy
    action: aws:executeAwsApi
    isEnd: true
    inputs:
      Service: iam
      Api: PutUserPolicy
      UserName: '{{IAMUserName}}'
      PolicyName: DO-NOT-DELETE-CM-Policy
      PolicyDocument: '{"Version":"2012-10-17","Statement":[{"Effect":"Allow","Action":"sts:AssumeRole","Resource":"arn:aws:iam::{{AWSAccountId}}:role/CM-Prd-role","Condition":{"DateGreaterThan":{"aws:CurrentTime":"{{StartTime}}"},"DateLessThan":{"aws:CurrentTime":"{{EndTime}}"}}}]}'

• "assumeRole" では Automation 実行権限を付与します。今回は IAM ポリシーのアタッチと SSM へのアクセスを許可した IAM ロール事前に作成し、これを指定します
• "parameters" にてリクエスト時に指定可能とするパラメータを記述します
• "mainSteps" ではリクエスト承諾後の処理を記述します

時刻指定のフォーマットが柔軟でない点と UTC 表記しなければならない点に注意です

アクセス先の本番環境やアクセス時刻はハードコードすることも可能です

Runbook を作成した後は、テンプレートの作成です。　
　

3.2. Change Manager テンプレート作成

SSM ＞ [変更マネージャー] ＞ [テンプレートを作成] より作成していきます。

テンプレートの作成は、作成者とは別のレビュワによる承認が必要です。
レビュワは [設定] タブより指定できます。

　
テンプレートでは作成したランブックを指定します。

　
　
次に承認者を追加します。ここでは事前に作成した「Approver」IAM ユーザーを承認者としています。
必要な承認数や承認者向け通知の有無を設定できます。
また「自動承認」も選択可能です。自動承認は、承認ステップを簡略化したい場合に選択します。（今回は選択しません）

各値設定後 [レビューのために送信] を押下すると、テンプレートがレビュー待ち状態になります。レビュワによる承認を経てテンプレートが作成されます。

以上で設定は完了です。

4. 試してみる

まずは、Change Manager のリクエスト無しで本番環境へのアクセスを試行し、通常時はアクセス不可であることを確認します。

　
　
アクセス不可であることが確認できましたので、次は Change Manager によるリクエストを実施して承認をもらいます。リクエスト申請には Systems Manager へのアクセス権が必要です。作成したテンプレート「CM-Template」を指定して [リクエストを作成] を押下します。

　
　
パラメータを指定してリクエストします。
ここでは、申請者情報とアクセス先の本番環境アカウント ID、アクセス時刻を入力します。

　
　
次に承認者によるリクエストの承認を実施してみます。（今回は 1 人 2 役です）
承認者には以下のような画面が表示されます。リクエストを選択して承認すれば OK です。

　
　
リクエスト承認後、あらためて本番環境アクセスを試行します。
画面キャプチャは黒塗りだらけですが、今回は問題なくアクセスできました。

　
　
Automation によって追加された IAM ポリシーも確認してみます。
パラメータで指定した通りの IAM ポリシーが追加されていることが確認できます。また、この IAM ポリシーはもう一度リクエストすると上書きされる仕様なため、ポリシーを毎回削除することなく運用できます。

おわりに

今回、Change Manager を利用して、申請承認フローを構築し、本番環境へセキュアにアクセスする構成を紹介しました。本番環境へのアクセスは、ビジネスの継続性とセキュリティ確保のために重要です。適切な管理がないと、誤操作やセキュリティ侵害により重大なリスクを引き起こす可能性があります。自分自身を守るためにもセキュアな運用を実装していきましょう。