この記事は公開されてから1年以上経過しています。情報が古い可能性がありますので、ご注意ください。
こんにちは 園部です。
AWS Systems Manager（以下、SSM）といえば、最近 Session Manager でアップデートがありましたね。
個人的にも興味深いものでした。
この辺りは弊社メンバーも取り上げてくれています。
- [ついに来た！？] AWS Systems Manager セッションマネージャーを OS ユーザー指定で使えるようになりました
- AWS Systems Manager セッションマネージャーでSSH・SCPできるようになりました
今日は、同時期に新しい機能として追加された 「パスワード変更」 機能について取り上げていきます。
You can reset the password for any user on a managed instance. This includes Amazon EC2 instances, on-premises servers, and virtual machines (VMs) that are managed by AWS Systems Manager. The password reset functionality is built on the AWS Systems Manager Session Manager capability. You can use this functionality to connect to instances without opening inbound ports, maintaining bastion hosts, or managing SSH keys.
This makes the password reset option useful when a user has forgotten a password, or when you want to quickly update a password without making an RDP or SSH connection to the instance.
（ 引用： 公式ドキュメント履歴より ）
日本語ドキュメントはまだ対応されていないため、翻訳サービスと拙い英語力によると以下の機能ようです。
- SSM の管理対象インスタンス（マネージドインスタンス）内の任意ユーザーのパスワードを変更する
- Session Manager を利用して変更する
- パスワード忘れへの対応がログインせずに出来ます
またドキュメントには、いくつかの条件や制限事項も記載されています。パスワード変更は重要な要素の一つですのでその辺りも交えてやっていきたいと思います。
やってみた
今回、Amazon Linux2 と Windows Server を用意してそれぞれに対して実施します。
前提条件
本機能を利用するには、以下の前提条件とデータ暗号化を行う必要があります。
一つずつ確認・設定を行なっていきます。
- SSM Agent がインストールされたマネージドインスタンス
- SSM Agent 2.3.668.0 以降
- Session Manager が利用可能
- （コンソール上で）実行するAWSユーザーに、ssm:SendCommand が必要
- AWS KMSによるデータ暗号化設定が必要
SSM Agent がインストールされたマネージドインスタンス
SSM Agent のインストールは割愛させていただきます。 以下の画面に、対象インスタンスが表示されていればマネージドインスタンスとなっています。
SSM Agent 2.3.668.0 以降
SSM Agent のバージョンはマネジメントインスタンスの一覧にて確認することも可能です。今回は、どちらもアップデートが必要です。
普段であれば、RunCommand から AWS-UpdateSSMAgent ドキュメントを実行しますが、今回は違う方法で行います。（個人的にはなんて優しい機能なんだろうかと半べそです）
（SSM Agent バージョンをチェックせずに） パスワードのリセット を実行します
すると...Agent バージョン古いからだめだぞうと注意されます。
通常ならここまでですが、 更新 を選択することでこの場でアップデートすることが可能です。。
裏側では、RunCommand が実行されています。
もちろん、複数台アップデートするなら最初から RunCommand で実施する方が効率的です。でもでも、門前払いじゃないのが優しい...
Session Manager が利用可能
こちらは利用可能という前提とします。
（コンソール上で）実行するAWSユーザーに、ssm:SendCommand が必要
検証のため AdministratorAccess 権限を持つユーザーで進めます。
AWS KMSによるデータ暗号化設定が必要
セッションデータを暗号化するため、AWS KMSを利用して暗号化設定を行います。
ちなみに、AWS KMS による暗号化を行わないと以下のようなエラーが表示されます。
先ほどの SSM Agent アップデートで気を良くして進めます。
この時点で、AWS KMS による暗号化を行うようにインフォメーションが出ています。
（ちょっと強引に）ユーザー名を入力し、 送信 を選択します。
一覧画面に戻り、上段にエラーメッセージが表示されます。
それでは、KMS にてキーの作成を行います。
今回は 「 blog-20190719 」 という名前で作成します。
（作成の詳細は割愛します）
Session Manager 画面に遷移します。
アクティブなセッションデータの KMS 暗号化を有効にする >>> Key Management Service (KMS) にチェックを入れ >>> 現在のアカウントの KMS キーを選択します で先ほどのキーを選択 >>> 保存 を選択
少し長くなりましたが、準備完了です。それでは、続いてパスワード変更を実施していきます。
Amazon Linux2 編
対象インスタンスには、以下のログインユーザーが作成されています。今回は、追加で作成した operator01 のパスワードを変更します。
$ cat /etc/passwd |grep bash
root:x:0:0:root:/root:/bin/bash
ec2-user:x:1000:1000:EC2 Default User:/home/ec2-user:/bin/bash
ssm-user:x:1001:1001::/home/ssm-user:/bin/bash
operator01:x:1002:1002::/home/operator01:/bin/bashAWS Systems Manager >>> マネージドインスタンス >>> アクション >>> パスワードのリセット を選択します
変更したいユーザー名を入力 >>> 送信 を選択します
表示されたプロンプト内で、新しいパスワードを入力します。
Done を選択
パスワードが変更されていることを確認します。通常であれば、ユーザーへスイッチ出来れば明瞭ですが、記事内でわからないのでいくつかの情報を確認します。
- /etc/shadow の暗号化された値が異なる
# less /etc/shadow |grep operator01
operator01:$6$N0yurZ/P$kGRMsbZ3y2BAi.IOQazO6oKMYsw8s9PtSzpgh4s63uN23fLW4.YBlxvndPSBx4Q1Ir4ybbPw97N5ioOiz5syS.:18096:0:99999:7:::
# less /etc/shadow |grep operator01
operator01:$6$LLPJexOh$e7lY0BZ2/m1mPkFkQLZVmrBGbU2jMkZZIUg5Aeq.2LDbe4DbZhLShA6.0qhWvWtfZmyl8eMeWXHVk1YK3UTcR1:18096:0:99999:7:::- /var/log/secure ファイル
# less /var/log/secure |grep password
Jul 19 06:57:34 ip-192-168-1-146 passwd: pam_unix(passwd:chauthtok): password changed for operator01- スイッチユーザー
$ su - operator01
パスワード:
最終ログイン: 2019/07/19 (金) 06:55:30 UTC日時 pts/1
[operator01@ip-192-168-1-146 ~]$Windows Server 編
Amazon Linux2 と同様に、デフォルトユーザー以外に operator01 を追加し、パスワードを変更します。
Remote Desktop Users グループに参加させておきます。
ログイン出来ます。
Amazon Linux2 と同様に マネージドインスタンスからパスワードを変更します。
パスワードが変更されていることを確認します。Windows Server も通常であれば、該当ユーザーで変更したパスワードでログイン出来れば明瞭ですが、記事内でわからないのでログから確認します。
- イベントログ（Security）
該当時間に 「User Account Management」 に関するログが出力されています。
順に見ていくと途中で 「A user account was changed.」 「An attempt was made to reset an account's password.」 ログが出力されています。
- 該当ユーザーでログイン
気になるところ
どちらのOSでも、パスワードを変更することが出来ました。準備が整っていればとてもシンプルに変更することが可能です。ただ実運用を想定すると、いくつかの懸念点が生まれてきます。 思いついた部分にはなりますが、ドキュメント記載の条件・制限事項と合わせて確認していきます。
ログ
Q. Systems Manager から変更したことは記録出来るのか？ログは取れるのか？
OS上のログは、上記で紹介したようにインスタンス内に記録されます。本機能自体は、Session Manager を利用したものになるため、Session Manager 設定にてログを残すことできました。 以下は、S3 に出力されたログとなります。
- Amazon Linux2 （綺麗なログ取得のため再取得しています。。）
- Windows Server
変更対象
Q. どんなユーザーでも変更することは出来るのか？
ドキュメントの冒頭にあるように、 any user on a managed instance となり、今回の環境では以下のユーザーでも変更が可能でした。
- Amazon Linux2
- ec2-user / ssm-user / root
- Windows Server
- ssm-user / Administrator
もちろん、Amazon Linux2 ではデフォルト パスワードによる ssh は禁止設定となっています。
Windows Server でも適切な権限を持たないユーザーはRDPによるアクセスは不可です。
パスワードを付与することは可能ですが、アクセスに関しては現在同様適切な設定を行うことより保護することが可能です。
コントロール方法
Q. Session Manager は利用させたいけど、パスワード変更は利用させたくない。
ドキュメントに、今回のパスワード変更機能を利用するには以下の権限が必要と記載があります。
- SSMドキュメント： AWS-PasswordReset
- ssm:StartSession 権限
以下のような IAM ポリシーを作成・追加することでコントロールが可能です。
検証はしておりますが、いざ本番運用される際は必ずテストをしてください。
Windows Server 初期パスワードの取得
Windows Server では 「初期パスワードの取得」 が提供されています。この機能への影響・関係はあるのか。
Q. 今回のパスワード変更機能で、Administrator のパスワードを変更すると、こちらで取得できるパスワードも変更されるか？
変更されませんでした。
Q. カスタムAMIで、「初期パスワードの取得」が出来ない場合、変更した内容でログイン可能か？
可能でした。
つまり、Administratorしか利用していないようなインスタンスで、カスタムAMIのAdministratorパスワードを万が一忘れてしまった場合、今回のパスワード変更機能を利用することでリカバリーすることが可能です。
さいごに
またSSMに素敵な機能がリリースされました。利用シーンに応じて活用することで運用の負荷の軽減が出来そうですね。
あぁ、あの時、あのとき、欲しかった...
2
