クラウドセキュリティエンジニアブログ

ニューリジェンセキュリティのクラウドセキュリティエンジニアチームが AWSなどのクラウドセキュリティについて気になることや調べたことを書くブログ

Change Managerによる変更管理と本番アクセス統制 ③Session Managerログイン&ロギング編

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

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

前回の「②マルチアカウント&IAM設計編」では、本番アクセス統制の前提となるマルチアカウント設計とIAM設計について紹介しました。
今回の「③ Session Managerログイン&ロギング編」では、エビデンス取得のためのSSHを使わないインスタンス接続やロギングについて紹介します。

Session Managerとは

AWS Systems ManagerというAWSリソースの構成や変更を管理するサービスがあり、Session Managerはその1機能です。
Session Managerを利用することで、SSHを使わずにAWSマネジメントコンソールからEC2へ接続することができます。

docs.aws.amazon.com

Session Managerを利用するメリット

Session Managerを利用するメリットをあげます。

HTTPSで接続できるため、SSHキーの鍵管理や通信許可が不要

HTTPSは空いているけど、社内ルールでSSHが制限されている組織は多いと思います。
また、SSHキーの管理にも気を使わなければならないため、運用負担が大きいです。
Session ManagerはHTTPSで接続できるため、手軽に導入することができます。

踏み台サーバが不要

パブリックサブネットだけでなく、プライベートサブネットに配置しているEC2へもアクセスできるため、踏み台サーバが不要になります。

パブリックIP/Elastic IPが不要

EC2へパブリックIP/Elastic IPを付与しなくても、接続することができます。
AWSではElastic IPの払い出し数は制限されていますが、そのような心配もなくなります。

Session Managerログインの前提条件

EC2にSSM Agentの導入が必要

Amazon Linux 2などデフォルトで導入されているケースがありますが、導入されていない場合は手動でインストールする必要があります。

EC2にSystems Managerへの適切な権限が必要

AWS管理ポリシー「AmazonSSMManagedInstanceCore」を含む権限が、インスタンスにアタッチされている必要があります。

インターネットを経由しない場合は、適切なVPCエンドポイントが必要

インターネットを経由しない完全に閉じた環境でSession Managerを使用する場合は、以下のVPCエンドポイントを用意し、それらにアタッチするセキュリティグループでインバウンド443ポートを許可する必要があります。

  • com.amazonaws.region.ssm
  • com.amazonaws.region.ec2messages
  • com.amazonaws.region.ssmmessages

Session Managerで接続してみる

実際に、Session Managerを使ってどのようにEC2に接続するのか、順を追って説明します。

IAMロールを作成

EC2がSystems Managerを使用するために、EC2にアタッチするIAMロールを作成します。
信頼されたエンティティタイプは「AWSのサービス」、ユースケースは「EC2」を選択します。

ポリシーは、AWS管理ポリシー「AmazonSSMManagedInstanceCore」を選択します。

任意のロール名を付けて、ロールを作成します。

EC2を作成

今回は、デフォルトでSSM Agentがインストールされている、Amazon Linux 2をプライベートサブネットに配置した構成にします。
任意の名前を付けて、Amazon Linux 2を選択します。

「キーペアはなしで続行」を選択します。

プライベートサブネットを選択します。
セキュリティグループはデフォルトでインバウンドSSHが設定されていますが、不要なので削除します。

インスタンスプロファイルは先ほど作成したロールを選択します。

インスタンスが起動できたので、一度接続を確認してみます。

VPCエンドポイントを設定していないので、この時点では接続できません。

セキュリティグループを作成

後に作成するVPCエンドポイント用のセキュリティグループを作成します。
インバウンドルールで、VPC CIDERからのHTTPSを許可します。

エンドポイントを作成

以下3つのエンドポイントを作成します。

  • com.amazonaws.region.ssm
  • com.amazonaws.region.ec2messages
  • com.amazonaws.region.ssmmessages

サービスのフィルターから検索して選択します。

EC2を配置しているVPCとサブネットを選択します。
セキュリティグループは先ほど作成したものを選択します。
ポリシーはデフォルトのフルアクセスのままにします。

同じ要領で他のエンドポイントを作成します。

Session Managerで接続

先ほどと同様に、EC2の画面からSession Managerで接続してみます。
今度は「接続」ボタンがアクティブになっているので、「接続」ボタンを押下します。

プライベートサブネットに配置したインスタンスに、Session Managerを使用して接続することができました。

Session ManagerでコマンドログをS3に保存する

本番環境のインスタンスであれば、操作履歴を取っておきたいものです。 Session Managerはコマンドログを取得する機能もありますので、順を追って説明します。
マルチアカウント構成の観点では、ログ保存専用アカウントを作成してログを集約するとよいので、クロスアカウントを想定した設定になります。

バケットを作成

ログ保存専用アカウントにログ保存用のバケットを作成します。

暗号化は「Amazon S3 マネージドキー (SSE-S3)」を選択し、その他の設定はデフォルトのままにします。

インスタンスがあるアカウントからクロスアカウントでロギングできるように、バケットポリシーを設定します。

バケットポリシーを設定して、「変更を保存」を押下します。

{
    "Version": "2012-10-17",
    "Statement": [
        {
            "Sid": "PutObject",
            "Effect": "Allow",
            "Principal": {
                "AWS": "arn:aws:iam::<accountID>:role/ssm-ec2-role"
            },
            "Action": "s3:PutObject",
            "Resource": "arn:aws:s3:::sessionmanager-log-bucket/*",
            "Condition": {
                "StringEquals": {
                    "s3:x-amz-acl": "bucket-owner-full-control"
                }
            }
        },
        {
            "Sid": "GetEncryptConfig",
            "Effect": "Allow",
            "Principal": {
                "AWS": "arn:aws:iam::<accountID>:role/ssm-ec2-role"
            },
            "Action": "s3:GetEncryptionConfiguration",
            "Resource": "arn:aws:s3:::sessionmanager-log-bucket"
        }
    ]
}

IAMロールを設定

S3にログを保存するためのインラインポリシーをロールに追加します。

S3保存と暗号化に必要な権限を付与します。

{
    "Version": "2012-10-17",
    "Statement": [
        {
            "Effect": "Allow",
            "Action": [
                "s3:PutObject"
            ],
            "Resource": "arn:aws:s3:::sessionmanager-log-bucket/*"
        },
        {
            "Effect": "Allow",
            "Action": [
                "s3:GetEncryptionConfiguration"
            ],
            "Resource": "*"
        }
    ]
}

S3エンドポイントを作成

インターネットを経由しない閉じた環境でS3に接続するため、S3エンドポイントをGateway型で作成します。

インスタンスが配置されているVPCと、サブネットで指定しているルートテーブルを選択します。

Session Managerのログ設定を有効化

Systems Managerの画面からSession Managerのログ設定を有効化します。

S3へのログ転送と暗号化を有効化し、転送先のバケットを指定します。

Session Managerで接続

EC2の画面から、Session Managerで接続します。

適当なコマンドを入力し、終了します。

Session Managerの画面で、セッション履歴が確認できます。

バケットにログファイルが格納されています。

まとめ

今回の「③ Session Managerログイン&ロギング編」では、エビデンス取得のためのSSHを使わないインスタンス接続やロギングについて紹介しました。

Session Managerを使うことで、AWSマネジメントコンソールからEC2に接続できるだけでなく、IAMによる制御ができるようになりました。
つまり、スイッチ先のロールにSession Managerの権限を付与しておけば、この仕組みにより自動的にエビデンス取得ができるようになります。

残る課題は、ユーザの本番環境へのスイッチロールを制御する方法であり、いよいよメインテーマである「Change Managerによる変更管理と本番アクセス統制」に入っていきます。

次回の「④Change Managerセットアップ編」では、変更管理と本番アクセス統制に利用するChange Managerのセットアップ方法を紹介します。

「Change Managerによる変更管理と本番アクセス統制」シリーズ全編はこちら

  1. 動機づけ編
  2. マルチアカウント&IAM設計編
  3. Session Managerログイン&ロギング編
  4. Change Managerセットアップ編
  5. テンプレート作成編
  6. 動作確認編
  7. まとめ