少し前ですが、AWSのSystems Managerにセッションマネージャー機能がリリースされました。
「これでSSHのインバウンドを塞いでEC2をセキュアにできる！」ということで、早速使ってみました。
セッションマネージャーは、ブラウザから開くAWSのマネジメントコンソール上からEC2インスタンスに対してシェルアクセスができるようになる機能で、SSH接続でログインした時と同様のCLI操作がブラウザ上で可能になります。
セッションマネージャーを使うメリット
1. EC2へのSSH鍵を持たずにログイン時と同レベルのサーバ作業が可能
上で書いた事を言い換えただけなんですが、組織に所属する各メンバーに対して適切に権限管理を行う事が求められる環境での運用時など、これが凄く大きいです。
各PCのローカル上にSSH鍵を持たずに済むのでセキュリティ上のリスクを抑えつつ、サーバ作業が必要な際にはブラウザ上から対応が可能になります。
作業を行うマネジメントコンソールへのログイン権限についても、常時ログインできるアカウントを用意せずにSTS(Security Token Service)を利用して必要になった時にだけ一時的な認証情報を取得するようにしておけば尚良いですね。
2. シェルアクセス後の操作記録が自動で残るのでシステム監査対応が楽
企業の業務で使用するシステムはシステム監査を受ける事が必須な時代になっており、その際の監査時の内容としてサーバ上で行った操作ログが保存されており後から確認可能である事はとても重要です。
その点、セッションマネージャーを経由したシェルアクセス時には全ての操作ログが自動でS3に保存されるようになっているので安心です。
保存先のバケットやパスなどは、セッションマネージャーの接続の設定欄から自由に設定できるようです。
3. EC2に設定するセキュリティグループのインバウンドからSSH用のポート解放を削除できる
今回試してみた最初の目的がこれだったのですが、よく考えるとインバウンドのSSHは接続元のIPが信頼できる場所からの場合のみ接続可能にする事がほとんどだと思うので、SSH鍵を持たずに済むようになるメリットの副次的なものぐらいの扱いでしょうか。
シェルアクセスを可能にする環境の作成
次に、セッションマネージャー経由でシェルアクセスを行いたいEC2に対して使用可能にする為の環境を作成していきます。
1. SSM エージェントのインストール
Systems Managerの機能を使用する為には対象インスタンスでSSM エージェントが動いている必要があります。
2017年9月以降に作成されたインスタンスにはデフォルトでインストールされているようですが、それ以前に作成されたインスタンスには手動でインストールする必要がある為、まずはインスタンスにログイン後に以下のコマンドを叩いてSSM エージェントのインストール状況を確認します。
|
1 |
sudo status amazon-ssm-agent |
上記コマンドを叩き、出力結果に以下が表示された場合はインストール済です。
|
1 |
amazon-ssm-agent start/running, process ${プロセスID} |
SSM エージェントが使用可能になっているので手順2に進みます。
逆に、出力結果に以下が表示された場合はまだインストールがされていません。
|
1 |
status: Unknown job: amazon-ssm-agent |
対象インスタンスでSSM エージェントが使える状態になっていない為、手動でインストールを行う必要があります。
SSM エージェントを手動インストールする方法は、対象インスタンスのOSやインスタンスタイプにより異なるので公式ページを見て適宜変更する必要がありますが、今回はAmazon Linuxのt2系インスタンスの為、以下でインストールしました。
|
1 |
sudo yum install -y https://s3.amazonaws.com/ec2-downloads-windows/SSMAgent/latest/linux_amd64/amazon-ssm-agent.rpm |
インストール後はもう一度 sudo status amazon-ssm-agent のコマンドを叩いて出力結果が変わる事を確認します。
2. SSMからの操作を可能にする為のロールを付与
次に、SSMからの操作を可能にする為のAmazonEC2RoleForSSMのポリシーが設定されたIAMロールを作成し、対象のEC2インスタンスに対してアタッチする必要があります。
マネジメントコンソールからEC2 → インスタンス → (対象インスタンスにチェックを付けた状態で)アクション → インスタンスの設定 → IAMロールの割り当て/置換 と進めていきます。
IAMロールの割り当て/置換 に進んだら、新しいIAMロールを作成する を選択。
* ポリシーが設定されたロールが既に存在する場合は、新規作成の必要はないです
ロールの管理画面に進んだら、ロールの作成 を選択。
* 同じく、ポリシー設定済ロールが既に存在する場合は、作成の必要はないです
このロールを使用するサービスを選択欄でEC2を選択した状態で 次のステップ:アクセス権限を選択。
設定するポリシーの選択画面に移ったら AmazonEC2RoleForSSM を選択した状態で 次のステップ:タグを選択。
タグは特に必要がないのでそのまま飛ばして（付けたい場合はご自由に）、最後の確認画面でロール名を付けて ロールの作成 を選択でIAMロールの完成です。
最後にIAMロールの割り当て/置換に戻り、作成したIAMロールを選択した状態で 適用 を選択すれば一連のインスタンスへのロール付与作業は完了です。
3. SSM エージェントのバージョンアップ
SSM エージェントは使用可能になりましたが、セッションマネージャーを使用する為にはSSM エージェントのバージョンが2.3.12以上である必要があるようです。
手順1で新規にSSM エージェントをインストールした場合は最新版が入っており問題ないですが、2017年9月以降に作成したEC2インスタンスでデフォルトでSSM エージェントが入っていた場合などは、インストールされているバージョンが古い可能性がある為、インストール済のSSM エージェントのバージョンを確認します。
SSM エージェントのバージョンは、Systems Manager → インベントリを選択後のダッシュボード最下部に表示される為、ここが2.3.12以上かどうかを確認します。
* EC2へアタッチしたIAMロールが反映されるまでにタイムラグがある関係で対象インスタンスが表示されないことがありますが、その場合は15分程度待つ or 対象インスタンスを再起動する事で表示されるようになるようです
今回は新規にインストールしたので最新バージョンになっておりアップデート不要でしたが、2.3.12未満の場合にはアップデート対応を行う必要があります。
SSM エージェントのバージョンをアップデートするには、Systems Managerのランコマンドを実行して行うようです。
今回は不要だった関係で行なっていないのと、公式サイトに詳しく書かれているので割合します。
アップデートの必要がある場合は、参照して対応してください。
以上でシェルアクセス可能にする環境作成は終わりです。
シェルアクセス時のログ出力設定の指定
セッションマネージャーを使用してシェルアクセスする事は可能になりましたが、実行時の操作ログの出力が初期設定では有効になっておらず、システム監査時の要件を満たせていません。
設定を変更して、シェルアクセス時の操作ログを残すようにしましょう。
ログ出力設定の変更は、Systems Manager → セッションマネージャーの 設定の指定 から行えます。
1. S3へのログ出力設定
Amazon S3 バケットへのセッション出力の書き込み欄の S3バケット にチェックを入れると、S3への書き込み時の設定を入力するフォームが出てくるので、それぞれ以下のように入力していきます。
– ログデータの暗号化
ログデータを暗号化して出力したい場合にチェックを付けます。
– S3 バケット名
出力先バケットをどこにするかの設定で、リストからバケット名を選択 or テキストボックスにバケット名を入力 のどちらかを選択します。
既存バケット一覧が表示される下のセレクトボックスから選ぶか、フリー入力で下のテキストボックスにバケット名を入力するかの二択です。
* ログデータを暗号化出力する場合は、バケットもデフォルト暗号化させる必要有
– S3 キープレフィックス・オプション
出力先パスのプレフィックスを指定します。
未設定だとバケット直下にログファイルが作成され散らかってしまう為、ssm_logs などの名前で用途が判別できるディレクトリ内にまとめておくと良さそうです。
2. CloudWatch Logsへのログ出力設定
CloudWatch Logsへのセッション出力の送信欄の CloudWatch Logs にチェックを入れると、CloudWatch Logsへの書き込み時の設定を入力するフォームが出てくるので、それぞれ以下のように入力していきます。
– ログデータの暗号化
ログデータを暗号化して出力したい場合にチェックを付けます。
– CloudWatch ロググループ
出力先ロググループをどこにするかの設定で、リストからロググループを選択 or テキストボックスにロググループを入力 のどちらかを選択します。
既存ロググループ一覧が表示される下のリストから選ぶか、フリー入力で下のテキストボックスにロググループを入力するかの二択です。
* ログデータを暗号化出力する場合は、ロググループも暗号化させる必要有
全てを入力し終えたら右下の 保存 を選択して、ログ出力設定は完了です。
実際にEC2にシェルアクセスしてみる
準備が整ったところで、実際に使ってみましょう。
セッションマネージャーの開始は、Systems Manager → セッションマネージャーの セッションの開始 から開始できます。
ターゲットインスタンス欄に表示された対象インスタンスにチェックを付けた状態で セッションの開始 を選択すればシェルアクセス開始です。
一覧に対象インスタンスが表示されない場合は、
- SSM エージェントがインストールされていない
- AmazonEC2RoleForSSMポリシーが設定済のロールがアタッチされていない
のどちらかが原因なので、シェルアクセスを可能にする環境の作成をもう一度やってみてください。
そんなこんなでシェルアクセスを開始し…
上記のようなコンソール画面が表示されれば接続成功です。
使ってみてわかったこと
- 接続時の初期ユーザーは、ssm-user
- パスワード無しでrootユーザーに変更可能
- ssh接続時にできる事は、セッションマネージャー経由でも大体できそう
- 厳密にはログイン状態ではなさそう
– .bashrcなどのシェル設定ファイルは読み込まれないので使えない
– lastで見ても履歴に残っていない - ローカルとのファイルDL/UPなどは不可
（ローカルから繋いでいる訳ではないので当たり前と言えば当たり前）
あとがき
シェルアクセス時の操作ログも確認し、それぞれちゃんと記録されていました。
S3
CloudWatch Logs
時代はどんどん便利になっていきますねー。
という事で、今回はおしまい！