EC2にSession Managerで安全に接続する
この記事について
きっかけ
業務でインフラ全般を担当させていただいてるのですが、踏み台サーバーのセキュリティが気になっていました。初めての本番インフラを任された私は不安で仕方ありませんでした。夜しか寝れない。
セキュリティ面での改善と、接続が楽になりそうなものはないかと調査していたところ、セッションマネージャーという素晴らしいものを発見しました。
この記事の内容
この記事は2021年3月現在の、SSMセッションマネージャーを利用してEC2インスタンスに接続＋暗号化ロググループにログを出すところまでをメモったものです。
もっと良い方法があるかもしれませんし、情報が古くなる可能性もあります。
SSMとは
SSMについて
AWS Systems Managerのことです。旧称が「Amazon Simple Systems Manager」なので、略称がSSMなのです。全然シンプルではないのでSimpleが削除されたのでしょうか。
SSMはオペレーション管理、アプリケーション管理、管理の変更、ノード管理、共有リソースの 5 つのカテゴリを持ちます。今回使用するSession Managerと、Run CommandはSSMのノード管理の一部機能です。
Session Managerについて
EC2インスタンスにコンソール上から安全にアクセスできる機能です。（コンソール以外からも可能）
インバウンドを全て拒否するセキュリティグループをつけたEC2にもアクセス出来ます。
とても安全ですね！
プライベートサブネットに設置してあるインスタンスへの接続も可能です。
Run Commandについて
EC2内のデータのアップデートなど、あらかじめ決められた処理が、コンソールでぽちぽち選択するだけで完了できる優れた機能です。
自作した処理をドキュメントとして登録することも可能なので、繰り返し使用する処理は登録しておくのがおすすめです。
実際に作成する
今回作成する内容
今回は、VPC、サブネットは作成済みで考えます。
またログインユーザーはadmin権限など大体の作業ができるやつを想定しています。
リージョンは東京（ap-northeast-1）を想定していますが、SSMができるリージョンなら同じことができると思います。
作業手順としては、下記の通りです。
- EC2インスタンスを作成
- EC2につけるセキュリティグループを作成し、EC2インスタンスのセキュリティグループを変更
- EC2につけるIAMを作成、インスタンスにIAMをアタッチ
- KMSでCMKを作成
- CMKを使用してロググループを作成
- SSMのRun Commandを使用して、SSMエージェントを更新
- セッションマネージャーにKMSと作成したロググループを登録
- セッションマネージャーを使用してEC2にアクセス
以降では、簡単な説明と私の作成手順を箇条書きで記述します。
1. EC2インスタンスを作成
パブリックIPが無くても接続する方法はありますが、簡単のため今回は自動割り当てパブリックIPを有効にして作業していきます。
NatGatewayやPrivateLinkなどを使用することで、プライベートサブネット配置のインスタンスでもSSMで接続することが可能です。
手順
- ダッシュボードからEC2を選択
- 「インスタンス」を選択
- 右上のボタンの「インスタンスを起動」を押す
- Amazon Linux 2 AMI (HVM)を選択
- 無料枠の
t2.microを選択し、つぎのステップへ - インスタンスの詳細の設定を一部変更
- ネットワークを任意のVPCに変更
- サブネットを任意のパブリックサブネットに変更（今回は自動割り当てを有効にするため）
- 自動割り当てパブリックIPを有効
- 他は特にいじらず、次のステップへ
- ストレージの追加は特にいじらず、次のステップへ
- タグの追加では、キー：Name、値：
SSM_hogehoge_serverなどの任意の名前をつける- どれが何のインスタンスかわからなくなるのを防ぐために名前はつけましょう！
- セキュリティグループの設定を変更
- 既存のセキュリティグループからdefaultの全て通すやつを選択
※この時にインバウンド許可0のセキュリティグループを選択してしまうと、AMI（簡単に言うとインスタンスの基本の設定情報）も弾かれてしまうので、作成時はデフォルトにします。 - 確認と作成へ
- 既存のセキュリティグループからdefaultの全て通すやつを選択
- キーペアを適当に選択して、インスタンスを作成
- SSH接続なしなので、絶対SSHなどで接続しない踏み台サーバーの場合、キーペアなしでOKです。
- 必要な場合は既存か新規か適当に選択して、インスタンス作成します。
2. EC2につけるセキュリティグループを作成し、EC2インスタンスのセキュリティグループを変更
ここでは、AMIのために開放されていたdefaultのセキュリティグループから、自作セキュリティーグループへの付け替えを行います。
インバウンドを０にすることで、SSM以外からアクセスされないようにします。
アウトバウンドを閉じてしまうと、SSMが動作しないようなのでそっちは開けっ放しです。
手順
セキュリティグループを作成する
- ダッシュボードからEC2を選択
- 「セキュリティーグループ」を選択
- 「セキュリティグループを作成」を選択
- 「セキュリティグループを作成」画面で、必要な情報を記述
- 基本的な詳細
- セキュリティグループ名：適当な名前を入れます。 ex: hoge_server_sg
- 説明：適当な説明を入れます。 ex: it is test sg
- VPC: 作成したインスタンスの所属しているVPCを選択します
- インバウンドルールとアウトバウンドルールはそのまま
- デフォルトでインバウンド：0,アウトバウンド：全て
- Tags
- 名前がもう一つ欲しい場合などは キー：Name,値：atarashii_tekitouna_namae
- 基本的な詳細
- 「セキュリティグループを作成」を選択
作成したセキュリティグループを踏み台サーバーに紐付ける
- 「インスタンス」を選択
- 作成したインスタンスを選び、画像のように「アクション」から「セキュリティグループを変更」を選択
- 「関連付けられたセキュリティグループ」で作成したセキュリティグループの付け替えを行う
- 関連付けられたセキュリティグループからdefaultを削除します。
- 検索バーから、先ほど作成したセキュリティグループを選択し「セキュリティグループを追加」を押します。
3. EC2につけるIAMを作成、インスタンスにIAMをアタッチ
SSMの利用をするためのポリシーとKMSを使用するためのポリシ−を、インスタンスにくっつけます。これが無いと許可していないことになるので、エラーが発生します。
手順
IAMポリシーを作成する
- ダッシュボードからIAMを選択
- 「ポリシー」を選択
- 「ポリシーの作成」を選択
- JSONタブに切り替えて下記に記述してあるコードを貼り付け、次のステップを選択
- タグは任意。確認に進む
- ポリシーの確認で名前、説明を記述し、「ポリシーの作成」を押す
- 貼り付けるポリシードキュメント
- 後で作成するCMKを利用できるようにするためのポリシー
- Resource箇所などをいじれば細かい設定も可能（アスタリスクは全て）
- 参考： 既存のインスタンスプロファイルに Session Manager アクセス許可を追加する の
「kms:Decrypt」について
{
"Version": "2012-10-17",
"Statement": [
{
"Sid": "",
"Effect": "Allow",
"Action": [
"kms:Decrypt"
],
"Resource": "*"
}
]
}
IAMロールを作成する
-
「ロール」を選択
-
「ロールの作成」を選択
-
「信頼されたエンティティの種類を選択」からEC2を選択し、次のステップへ
-
Attachアクセス権限ポリシーからポリシーを２つ選択し、次のステップへ
- 先ほど自作したポリシーを選択（チェックをつける）
- 「AmazonEC2RoleforSSM」を選択
- これはRun CommandやSession Managerを使用できる権限です。
- Session Managerに接続するだけなら「AmazonSSMManagedInstanceCore」
参考： 既存のインスタンスプロファイルに Session Manager アクセス許可を追加する
参考： EC2 インスタンスでコマンドをリモートで実行する - 厳格に作成してみたい場合は公式のAWS Systems Manager Run Commandなどを見ると良いかもしれません。
-
ロールの作成でロール名と説明を適当に記述し、「ロールの作成」を押す
作成したIAMロールをEC2に紐付ける
- 「インスタンス」を選択
- 作成したEC2を選び、画像のように「アクション」から「セキュリティ」を押し「IAMロールを変更」を選択
- 上記で作成したIAMロールを選択して保存
4. KMSでCMKを作成
セッションマネージャーのやり取りとログを暗号化するための鍵を作成します。大切なデータ情報がログに出力されてしまう可能性があるので、暗号化はしておくべきです。ログを取らない場合は、この章と次の章を飛ばしてください。
KMSとは
KMSの正式名称は、Key Management Serviceです。
データの暗号化、復号化に使用する鍵をAWS上で管理するサービスです。
CMKとは
CMKはCustomer master keysです。その名の通りマスターキーです。
作成したCMKは削除すると、利用していたサービスの復号が完全に不可能になるようなので、一度作成したら、削除は慎重にしましょう。
CMKには「対象」と「非対称」の種類があります。
今回は「対象」のCMKを作成していきます。
参考になった記事
CMKの料金
保持管理と利用料金の２つがかかります。
- 保持管理
ローテーションなどを設定していない場合は、基本的に１USD/月の料金です。
この記事を試したら削除しましょう。 - 利用料金
20,000件/月の無料利用枠があるので、試すだけでは料金が発生しません。
東京リージョンでは10,000 件のリクエスト当たり0.03USDなので、頻繁に使用しなければそこまで料金はかさみません
参考： AWS Key Management Service の料金
手順
CMKを作成する
- ダッシュボードからKMSを選択
- 「今すぐ始める」の「キーの作成」or「カスタマー管理型のキー」を選択
- 辿り着く先は同じ
- キーのタイプを対象に選択、オプションはKMSのままで次へ
- エイリアス、説明、タグを追加し、次へ
- エイリアスはコンソール上では変更できないようなので慎重に設定
- CLIを使用することで変更、削除は可能な模様
- 参考: [小ネタ]KMSカスタマーキーのエイリアス名を変更する方法
- 説明とタグは任意
- エイリアスはコンソール上では変更できないようなので慎重に設定
- キーの管理者、キーの削除を選択し、次へ
- 作業ユーザーを設定しておけば、（設定してなくてもadminなら）あとで変更が可能
- キーの使用アクセス許可を設定し、次へ
- 作業ユーザーを「キーの管理者」に設定しておけば、（設定してなくてもadminなら）あとで変更が可能
- 完了を選択
作成したCMKのポリシーを変更する
- 先ほど作成したCMKを選択
- 「キーポリシー」の箇所にある、「ポリシービューへの切り替え」を選択
- 「編集」を選択し、下記のコードのように変更し、変更の保存を選択
{
"Sid": "Allow use of the key",
"Effect": "Allow",
"Principal": {
"AWS": [
"arn:aws:iam::xxxxx:user/taro",
"arn:aws:iam::xxxxx:user/jiro"
],
"Service": "logs.ap-northeast-1.amazonaws.com"
},
"Action": [
"kms:Encrypt",
"kms:Decrypt",
"kms:ReEncrypt*",
"kms:GenerateDataKey*",
"kms:DescribeKey"
],
"Resource": "*"
},
実際にやることは、Allow use of the keyの"Principal"に、"Service": "logs.ap-northeast-1.amazonaws.com"を追加しているだけです。
何をしているかというと、東京リージョンのclowdwatchに利用を許可しているだけです。
キーの使用許可に誰も選択していないと、上記のコードが無いと思います。適当なユーザーを選択しておいて、この処理の時に"AWS":...の箇所を削除する方法がわかりやすいです。
参考： AWS Key Management Service を使用した CloudWatch Logs でのログデータの暗号化
CMKのポリシーの注意点
キーポリシーは作成すると自動で、下記のポリシーを追加します。
{
"Sid": "Enable IAM User Permissions",
"Effect": "Allow",
"Principal": {
"AWS": "arn:aws:iam::xxxxxx:root"
},
"Action": "kms:*",
"Resource": "*"
}
上記はルートユーザーにフルアクセスを許可するものです。
この箇所を間違えて削除してしまうと、設定したユーザー以外触れることができなくなってしまうので注意が必要です。
誰もアクセス出来なくなってしまった場合は、AWS側に問い合わせしなければならないようです。
5. CMKを使用してロググループを作成
作成したCMKを使用してロググループを作成していきます。
手順
- KMSの画面から作成したCMKを選択
- 「一般設定」のARNをコピー
- コンソール上からcloudwatchを選択
- 「ログ」の「ロググループ」を選択し、「ロググループを作成」を押す
- ロググループ名、保持期間の設定を適当に入力
- 「KMS key ARN - optional」に先ほどコピーしたCMKのARNをペースト
- 「KMSキー ID オプション」という表記だったこともある。
- 作成
6. SSMのRun Commandを使用して、SSMエージェントを更新
最初から入っているSSMエージェントでは、ログの出力が出来ません。
他にも問題がありそうなので、とりあえず更新しておく方が良いと思います。
自動更新をすることができるようですが、今回は手動で行います。
自動化したい場合はSSM エージェント への更新の自動化などを参考にしてください。
手順
- コンソールからSSMを選択
- 「ノード管理」の「Run Command」を選択
- 「コマンドを実行する」を選択
- アップデートに必要なものを選択し実行
- コマンドドキュメントから「AWS-UpdateSSMAgent」を選択
- 「ターゲット」の「インスタンスを手動で選択する」を選択
- 出力オプションを任意に選択
- 「Run Command」のコマンドとコマンド履歴を確認して成功を待つ
7. セッションマネージャーにCMKと作成したロググループを登録
セッションマネージャーにCMKとログループを登録します。
CMKを登録することで、やりとりがCMKでさらに暗号化されより安全になります。
ロググループにCMKで暗号化したものを選択することで、ログも暗号化できます。
CMKは個別に登録が出来ないようです。どのEC2にアクセスする場合でも、ログ出力箇所とCMKは同じになります。
手順
- コンソールからSSMを選択
- 「ノード管理」の「セッションマネージャー」を選択
- 「設定を行う」を選択
- 「General preferences」の「KMS encryption」をチェックし、作成したCMKを選択
- 「CloudWatch logging」の内容を設定し保存
- 「Enforce encryption」の「Allow only encrypted CloudWatch log groups」にチェックし、リストから作成したロググループを選択
8. セッションマネージャーを使用してEC2にアクセス
いよいよ接続します。
インスタンスの接続からも利用出来ますが、一応セッションマネージャーから接続します。
セッションマネージャーの注意点
Safariの挙動
2021年3月現在、Safariで接続するとコマンドが打ち込めないようです。
Chromeを使用しましょう。
ユーザー名と初期位置
セッションマネージャーで接続した時の位置は、/usr/binです。
ユーザー名はssm-userとなります。ec2-userではないので気をつけてください。
手順
- コンソールからSSMを選択
- 「ノード管理」の「セッションマネージャー」を選択
- 「セッションの開始」を選択
- ターゲットインスタンスから、接続したいインスタンスを選択し、「セッションを開始する」を選択
- 接続完了！
- コマンドがリアルタイムに作成したロググループに反映されます。
- 誰がどんなコマンドを打って、レスポンスはなんだったかが記録されるので安心ですね！
終わりに
お疲れ様でした。これで完成です。
初めて記事を書きましたが、書いている最中に気になることが出てきて調べる、を繰り返すうちにとても時間がかかってしまいました。ただ、記事を書く前より今回の事象に詳しくなれたので、よかったです。
不要な箇所も含めて丁寧に書きすぎた気がするので、次回は気をつけたいと思います。
今回作成したものは、（特にcmkは）放置していると料金が発生してしまうものがあるので、試しに作成した場合は削除しておくことをおすすめします。
アドバイスをいただけると勉強になりますので、細かいことでも教えていただけると嬉しいです。
ありがとうございました。
Discussion