Chatbotと時間限定IAMポリシーを使用した本番接続運用を考える
こんにちは。上野と申します。
Japan APN Ambassador Advent Calendar 2020 10日目のエントリです。AWSさんに挟まれた日程で記事を書いております。ほかの方の記事も、おもしろいものばかりですので是非読んでみてください。
Ambassadorって何？というかたは下記の記事を読んでもらえるとわかると思います。
私は2020年にAmbassadorとして選んでいただきました。資格取得や登壇、執筆などが評価され、選出いただいたと考えています。
本エントリの内容について
私は技術的なネタを書きます。
コロナウィルスの影響で在宅勤務が増えるなか、みなさま本番システムのアクセスはどう管理していますでしょうか。 オフィス内に本番接続ルームを用意して、そこからアクセスするという運用をされている方も多いと思います。
ただ、今後もコロナの状況が続くとなると、中々オフィスに出向くのは厳しいかもしれません。そこで私からは本番アクセスの一例として、Chatbotと時間限定IAMポリシーを使用したアクセス運用を紹介したいと思います。
実際に運用で使っているわけではなく、私の1アイディアですので参考として読んでいただけると幸いです。
使用するサービスについての前知識
Chatbot
Chatbotは、SlackやAmazon ChimeのチャットツールとAWSを連携するサービスです。チャットでメッセージ送信をトリガーにLambda関数を実行できるため、今回はそれを使用します。
なお、Chatbotを準備してLambda関数を実行するまでの内容は以下記事で解説しています。
時間限定IAMポリシー
IAMポリシーには、ConditionにDateLessThanを指定することで、時間限定のAWSアクセスを付与できます。 今回はこれを使用して一時的なアクセスをユーザーに付与します。
「IAMポリシーの例」
{ "Version": "2012-10-17", "Statement": [ { "Effect": "Allow", "Action": "*", "Resource": "*", "Condition": { "DateGreaterThan": {"aws:CurrentTime": "2020-04-01T00:00:00Z"}, "DateLessThan": {"aws:CurrentTime": "2020-06-30T23:59:59Z"} } } ] }
参考： AWS: 日付と時刻に基づいてアクセスを許可する - AWS Identity and Access Management
運用方法（利用時）の流れ
技術的な点は一旦置いておいて、どのような流れで一時アクセスを付与するのか流れで説明します。
１．デフォルトの状態＝何もできない
デフォルト状態では、IAMポリシーを空にしておき、IAMユーザーはログインのみできる状態にしておきます。
この状態でログインしてEC2の画面を表示すると、以下のとおりAPIエラーとなり各種情報が表示されません。 本番の運用状況にもよりますが、例えばデフォルトRead権限はつけておくというポリシーもありかと思います。
２．Slack経由でIAMユーザーに権限を付与する。
IAMユーザーが本番アクセス（AWSへログイン）が必要になったとします。
管理者がSlack上に↓のメッセージを実行することで、指定したユーザーに権限が付与されます。
ここではユーザー名をprd-userとします。--payloadオプションでIAMユーザー名を指定しています。
@aws lambda invoke temp-access --payload {"user":"prd-user"}
すると以下の通りChatbotが実行するか質問してくるので、Yesを押します。
Lambdaが実行されます。「End time is・・」に記載されている時刻は、 IAMユーザーのアクセスが不可となる時間です。（UTCで表示されてます）
※時刻の設定やレスポンスはLambda内でもろもろ実装
この時点でアクセス権限が付与されました。
３．IAMユーザーログイン
アクセス権限が付与されたので、アクセスしてみます。
以下のように、先ほどAPIエラーとなっていた各数値の情報が表示されました。 これでアクセスが可能になったことがわかります。
今回はIAMユーザーにAdministratorAccess同様（全許可）のポリシーを時間限定で付与しています。 実運用では、本番運用に必要な権限のみ許可するほうが良いでしょう。
４．指定時間経過後
指定した時間が経過すると、以下のようにまた情報が表示されなくなります。特に再ログインは無しで、画面遷移していると急にエラーになります。
そのため設定する利用時間は慎重に設定する必要があります。また、ChatbotからLambdaを再実行すれば期間延長可能です。
運用方法はここまでです。
技術情報の補足
ソースコードは以下githubに置いています。 CloudFormationテンプレート（CreateTempIAMPolicy.yml）をデプロイすれば、Lambda関数が作成されます。 Chatbot経由のLambda実行は繰り返しになりますがこちらの記事を参考にしてください。
アーキテクチャは以下の通りです。 LambdaがIAMポリシーを付与するだけという、割とシンプルなつくりです。
その他いくつか実装面の補足情報を書いておきます。
- 利用可能な時間は、Lambda関数の環境変数で設定しています。CloudFormationテンプレートのデフォルトは180で、単位は分です。（3時間）
- IAMポリシーはIAMユーザーにインラインポリシーとして設定しています。通常ポリシーを一元管理にするために、管理ポリシーを付与してそれをIAMグループに付与するのが一般的ですが、今回は指定したユーザーのみに付与するためインラインにしました。
- 指定時間が経過しても、インラインポリシー自体は残り続けます。ただし時間切れ状態です。再度Lambda関数が実行されると、ポリシーが新しい時間で上書きされます。
実運用上での考慮事項
実際の本番運用で使う場合は、この実装だけでは足りず、追加で考慮も必要になるかと思います。 いくつか検討事項として出てきそうなところを書いてみます。
IAMポリシーについて
運用方法の流れでも書いたとおり、例では許可するActionとResourceを*（＝全許可）で指定しているため、実際の運用では本番運用で必要な権限のみ指定して許可する必要があります。 また、IAMポリシーではIP制限をかけたり、MFAを強制させることもできますので、そういった追加のセキュリティポリシーを追加するとよりセキュアなアクセスが実現できます。
本番持ち出しについて
IP制限など、特定の端末にアクセスを絞らない場合は、データの端末への持ち出しが気になるところです。以下は1つの例ですが、WorkSpacesを本番アクセス仮想端末として使用することで、ファイルの端末への書き出しを防ぐことができます。
WorkSpacesへのログインは、クライアント証明書ベースの認証もできるので、証明書が入った端末のみアクセス可能といった制御もできますね。
VPC内へのアクセスについて
VPC内にEC2を多く配置していると、EC2にSSHでログインすることもあるかと思います。
私としては、サーバーに直接SSHアクセスするのではなく、Systems ManagerのSession Managerを使用してサーバーアクセスするのが良いと思います。こうすることでサーバアクセスの認証もIAMで一元管理できるからです。操作ログも取得も可能です。Session Managerの使い方はこちらに書いています。
Chatbotの利用について
今回、Slackの特定のチャンネルからChatbotを実行できるようにしているのですが、このチャンネル内のユーザーであれば誰でもLambda関数が実行可能となります。そのため、管理者のみのプライベートチャンネルにしたほうが良いです。
Lambda側で呼び出したSlackユーザー情報が取れれば、ユーザーに応じて処理実行有無を制御できるのですが、現状Slackユーザー情報は取得できないようです。
まとめ
すいません、なんだか長くなってしまった気がします。
本番運用されている方、アクセス方法に悩まれている方も多いかと思いますので、何かの参考になれば幸いです。
今回ご紹介したのは1つの手段です。アクセス手段を作ることは目的ではなく、本番上の情報を守ることが本来の目的かと思いますので、どういったら守れるのか、そういった観点でアクセス方法も考えていきたいですね。
ありがとうございました、明日のアドベントカレンダーもお楽しみに！！
