AWSSSMを使用したSSHロギングとセッション管理

LinuxでSSHログを保持するためのカスタムツールまたはスクリプトの設定は、面倒でエラーが発生しやすい場合があります。

エンジニアは、 rootsh 、 screen 、または別のユーティリティを使用してユーザーアクティビティをログに記録できますが、ユーザー権限が正しく設定されていない場合、熟練したユーザーは監査ログを消去して自分のトラックをカバーできます。 もう1つのオプションは、カーネルレベルでロギングを設定することですが、それに必要な専門知識はそれほど一般的ではありません。

ありがたいことに、Linuxコマンドを1つも記述せずに、ユーザーアクティビティをログに記録する方法があります。 次のサービスが必要になります。

• EC2
• IAM（IDおよびアクセス管理）
• KMS（鍵管理サービス）
• CloudWatchログ（および/またはS3）
• AWS Systems Manager（旧称SSM）

それぞれの設定方法を見てみましょう。

EC2とIAM

EC2インスタンスの起動は通常かなり簡単ですが、起動中に実行する必要のある重要なタスクが1つあります。インスタンスにIAMロールをアタッチする必要があります。そうしないと、この最後に詳述されている期待される結果を達成できません。記事。

EC2インスタンスに関連付けるIAMロールには、組み込みのAmazonSSMManagedInstanceCoreポリシーに加えて、このポリシー（インラインまたはカスタマーマネージドとしてアタッチされている）が必要です。

 { "Version": "2012-10-17", "Statement": [ { "Action": [ "logs:CreateLogStream", "logs:DescribeLogStreams", "logs:DescribeLogGroups", "logs:PutLogEvents" ], "Effect": "Allow", "Resource": "*" } ] }

IAMの役割とは別に、通常は次のEC2インスタンス構成を使用します。

• OSはAmazonLinux2です。これは、デフォルトでAWS Systems Manager Agent（SSM Agent）がインストールされているためです。 （Ubuntuディストリビューションも同様です。これもオプションです。）
• インスタンスタイプはt3.microです（ただし、どのタイプでもかまいません）。
• この演習ではSSHポートを開く必要がないため、AWSがVPCに割り当てるデフォルトのセキュリティグループが機能します。

EC2インスタンスが起動するのを待たずに、KMSのセットアップを開始できます。

KMS

CloudWatchに配信されるすべてのセッションログを暗号化して保存する場合は、KMSキーが必要です。 KMSサービスに行き、キーを作成しましょう。

AWSアカウントのrootユーザー以外のユーザーがキーを管理できるように管理者を割り当てることをお勧めしますが、他のユーザーがアクセスする必要がない場合は、手順3をスキップできます。

ここでは、IAMユーザー「admin」をキー管理者として選択しましたが、任意のユーザーまたはロールを自由に選択できます。 管理者のキー削除権限を無効にすることもできます。

このキーは、SSHログの暗号化および復号化操作のためにCloudWatch Logsサービスでのみ使用されるようにするため、このキーにユーザーを割り当てることはありません。

レビューページでは、CloudWatch Logsがキーを使用するためのパーミッションが含まれていないため、KMSで生成されたキーポリシーを変更する必要があります。 これを次のポリシーに置き換えます。

 { "Version": "2012-10-17", "Statement": [ { "Sid": "Enable IAM User Permissions", "Effect": "Allow", "Principal": { "AWS": "arn:aws:iam::ACCOUNT_ID:root" }, "Action": "kms:*", "Resource": "*" }, { "Sid": "Allow access for Key Administrators", "Effect": "Allow", "Principal": { "AWS": "arn:aws:iam::ACCOUNT_ID:user/USERNAME" }, "Action": [ "kms:Create*", "kms:Describe*", "kms:Enable*", "kms:List*", "kms:Put*", "kms:Update*", "kms:Revoke*", "kms:Disable*", "kms:Get*", "kms:Delete*", "kms:TagResource", "kms:UntagResource", "kms:ScheduleKeyDeletion", "kms:CancelKeyDeletion" ], "Resource": "*" }, { "Sid": "Allow access to CloudWatch Log", "Effect": "Allow", "Principal": { "Service": "logs.REGION.amazonaws.com" }, "Action": [ "kms:Encrypt", "kms:Decrypt", "kms:ReEncrypt*", "kms:GenerateDataKey*", "kms:DescribeKey" ], "Resource": "*", "Condition": { "ArnLike": { "kms:EncryptionContext:aws:logs:arn": "arn:aws:logs:REGION:ACCOUNT_ID:*" } } } ] }

必ずすべてのプレースホルダーを置き換えてください。

• ACCOUNT_IDがAWSアカウントIDになります。
• USERNAMEは、手順3で選択した管理者ユーザー名になります。この手順をオプトアウトした場合は、ここで2番目のステートメントブロック（ "Sid": "Allow access for Key Administrators" ）を削除します。
• REGIONは、サービスをデプロイする地域IDコードになります（例： us-west-1 ）。

これで、KMSの準備が整いました。

CloudWatchロググループ

次に、SSMエージェントがSSHセッションログを送信できるCloudWatch Logグループ（および/またはS3バケット-以下を参照）が必要です。 作成しましょう。

KMSキーのARNフィールドに注意してください。AWSは、KMSセクションのステップ5でキーが作成された後、ここで必要な値を提供します。

（以前に正しいポリシーをKMSキーに関連付けておらず、CloudWatch Logsサービスがキーを使用できるようにした場合、この時点でKMSキーに関連するエラーが発生します。）

SSHログをS3バケットに保存する

CloudWatch Logsの代わりに（またはCloudWatch Logsに加えて）S3でアクティビティログを保存するには、これらのパーミッションを別のポリシーとしてEC2インスタンスプロファイルに追加する必要があります（または、関連付けが必要な他のパーミッションと手動で組み合わせる）。

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

上記のスニペットでは、必ずBUCKET_NAMEプレースホルダーを置き換えてください。

ログを保存する場所（CloudWatch Logs、S3バケット、またはその両方）を設定したので、SSHセッションを利用する準備が整いました。

AWSSystemsManagerセッションマネージャー

これが最後の重要なステップであり、SSHセッションの監視とロギングのためにLinuxマシンへの安全なアクセスを構成します。 まず、SessionManagerダッシュボードから始めます。

ダッシュボードで、右上の[セッションの開始]ボックスにある白い[設定の構成]ボタンをクリックして、セッションログを有効にします。

[設定]ページには、探索できる複数のセクションがありますが、Linuxマシン内で何が起こっているかをすばやく確認できるようにSSHセッションログをCloudWatchまたはS3にストリーミングすることに焦点を当てます。

「CloudWatchlogging」セクションの直後に、バケットを選択できる「S3logging」セクションがあります。

SSHロギングが構成されたら、LinuxマシンにSSHで接続し、いくつかのコマンドを実行して、アクティビティがキャプチャされているかどうかを確認できます。

それでは、セッションを開始しましょう。 同じページに、セッションを開始できる「セッション」タブがあります。 [セッションの開始]ボタンをクリックすると、セッションを開始できるEC2マシンのリストが表示されます。

リストにEC2Linuxインスタンスが表示されない場合は、EC2 Linuxインスタンスが実行状態にあり、前に説明したIAMアクセス許可が関連付けられているかどうかを確認する必要があります。

SSMエージェントの処理「ストリーミングログをサポートしていません」エラー

EC2マシンにインストールされているSSMAgentバージョンがCloudWatchログのストリーミングをサポートしていないというエラーを受け取った場合でも、心配する必要はありません。 これを修正する簡単な方法があります。

SSMエージェントを更新するには、 AWSSystemsManagerサービスの左側のパネルにある[コマンドの実行]に移動する必要があります。

そこに着いたら、オレンジ色の「コマンドの実行」ボタンをクリックすると、いくつかのパラメーターを入力できる新しいページが表示されます。

リストからAWS-UpdateSSMAgentを選択することから始めます。

それを選択したら、「ターゲット」セクションが表示されるまで下にスクロールします。 そこで、SSMエージェントを更新するEC2インスタンスを選択し、最後に「実行」ボタンを押す必要があります。 これにより、更新の進行状況を監視できるページに移動します。

エージェントの更新には5分以上かかることはありません。 これが完了すると、セッションマネージャーでセッションを作成できるようになります。

この時点で、SSHセッションを開始する必要があります。

いくつかのコマンドを実行した後、CloudWatch Logsロググループ（またはS3バケット、表示されていません）に移動して、アクティビティが記録されていることを確認しましょう。

これで、保存時の暗号化を有効にして、Linuxマシンで実行されたすべてのコマンドを記録するセットアップが完了しました。

実際、すべてのコマンドは私たちが望む以上のものである可能性があります。セッション中に提供または生成されたシークレットはCloudWatchまたはS3に記録され、必要なアクセス許可を持っている人なら誰でも見ることができます。 これを防ぐために、 stty -echo; read passwd; stty echo; stty -echo; read passwd; stty echo; セッション中に提供する必要のあるシークレットごとに。

マイナーな警告を伴う優れたSSM/SSHAWSロギングソリューション

Session Managerは、ポート22を開かなくてもAWSの仮想マシンにリモートアクセスするための便利なツールです。実際、Session Managerとしてポート転送または直接SSH接続を使用する場合、この方法でSSHログを生成することはできません。ドキュメントノート。

それでも、Session Managerとセッションロギングを組み合わせることは、VM内のアクティビティを制御および監視するための堅牢なソリューションです。 さらに、SessionManagerサービスの使用に対して料金が発生することはありません。 EC2インスタンスとCloudWatchLogs、またはログを保存するためのS3バケットに対してのみ料金を支払います。

ビデオチュートリアルを好む読者のために、YouTubeで非常によく似た手順をもう少し詳しく説明しました。

Toptal Engineeringブログでさらに読む：

• ケーススタディ：製品にAWSクラウドインフラストラクチャを使用する理由