こんにちは、クラウドセキュリティアーキテクトの大島悠司です。
7編にわたって、「Change Managerによる変更管理と本番アクセス統制」について紹介しています。
前回の「⑤テンプレート作成編」では、本番アクセス統制を実現するために、Change Managerに必要なテンプレートの作成と登録方法を紹介しました。
今回の「⑥動作確認編」では、Change Mangerのリクエスト作成を行ってみて、変更管理と本番アクセス統制が可能になっているかを紹介します。
Change Managerで本番アクセスする
前提
JumpアカウントのIAMユーザ member01が、本番環境の変更作業のためにProdアカウントにスイッチロールするケースを想定します。
Prodアカウントにはあらかじめ、以下のような本番作業用ロールが作成されています。
- Jumpアカウントには以下のような本番アクセス用グループが用意されており、上記のProdにある本番作業用ロールにスイッチする権限があります。
- member01は本番アクセス用グループに参加していません。
本番環境へスイッチロールしても当然失敗します。
リクエストを作成①
Change Managerから「リクエストを作成」を押下します。
グループ追加用のテンプレートを選択します。
変更の名前を付けます。
ターゲット通知トピックを選択し、「通知を追加」を押下します。
ロールはドキュメント作成時にデフォルトの設定をしているため変更は不要です。
ランブックのパラメータは、リクエストするユーザ、加入したいグループ、作業終了日時を入力します。
「承認のために送信」を押下します。
リクエストが保留中になり、選択したターゲット通知トピックからメールが届きます。
承認者グループのユーザがリクエスト画面を確認すると、承認/拒否ボタンがありますので「承認」を押下します。
コメントを記入して承認します。
ランブックのタスクが実行され、成功になりました。
タイムラインも確認できますので便利です。
変更結果を確認①
partner01が新たに本番アクセス用グループに参加し、タグが付与されています。
もう一度、Prodアカウントにスイッチロールしてみます。
今度はProdアカウントにスイッチロールできました。
リクエストを作成②
変更作業が終了したので、今度はグループから離脱するリクエストを作成します。
要領は先ほどと同じです。
タスクの実行が成功しました。
変更結果を確認②
partner01が本番アクセス用グループから離脱され、タグも削除されています。
当然、Prodアカウントにスイッチロールできなくなっています。
作業終了のリクエスト忘れへの対策
Change Managerにより、本番環境アクセスを制御できるようになりました。
リクエスト作成時にリクエスト情報を書き込めるようになっているので、あらかじめ作業計画や切り戻し計画を書いてもらう運用にすると、さらに管理しやすくなるでしょう。
ただ、ここまでの設定だけだとユーザから作業終了リクエストが行われなかった場合、本番アクセス用グループに参加し続けることができるので本番アクセスが常に可能になってしまいます。
そこで、ユーザに付与したタグが活きてくるわけです。
タグキーにグループ名、タグ値に作業終了日時を付与しているので、これを自動的に監視する仕組みを実装すればよいのです。
例えば、以下のようなLambdaを定期的に実行するとよいでしょう。
- 全ユーザのタグ値と現在日時を比較する
- タグ値 < 現在日時 なら、タグとともにタグキーに記載のグループから離脱させる
- 強制離脱させた場合やタグ値のフォーマット誤りがあれば、エラーメールを出す
このようなエラーメールがあれば運用しやすいのではないでしょうか。
まとめ
今回の「⑥動作確認編」では、Change Mangerのリクエスト作成を行ってみて、変更管理と本番アクセス統制が可能になっているかを紹介しました。
非常に使い勝手がよく、セキュリティやガバナンスの向上に役立つことを実感できたのではないでしょうか。
次回の「⑦まとめ」では、これまでの内容のポイントを振り返りたいと思います。