皆さん、IAM使ってますか〜？
今日は、IAMのベストプラクティスの中に呪縛のように存在する、最小権限をテーマに悩みを語ってみようと思います。
IAMでのセキュリティのベストプラクティス
まずは、IAMのベストプラクティスの確認です。2020年7月現在では、17個存在しています。一番最後のビデオで説明するの唐突感以外は、どれも納得感がある内容で実践・遵守すべきです。
- AWS アカウントのルートユーザー アクセスキーをロックする
- 個々の IAM ユーザーの作成
- IAM ユーザーへのアクセス許可を割り当てるためにグループを使用する
- 最小権限を付与する
- AWS 管理ポリシーを使用したアクセス許可の使用開始
- インラインポリシーではなくカスタマー管理ポリシーを使用する
- アクセスレベルを使用して、IAM 権限を確認する
- ユーザーの強力なパスワードポリシーを設定
- MFA の有効化
- Amazon EC2 インスタンスで実行するアプリケーションに対し、ロールを使用する
- ロールを使用したアクセス許可の委任
- アクセスキーを共有しない
- 認証情報を定期的にローテーションする
- 不要な認証情報を削除する
- 追加セキュリティに対するポリシー条件を使用する
- AWS アカウントのアクティビティの監視
- IAM ベストプラクティスについてビデオで説明する
『最小権限を付与』する難しさ
しかし、実際にこのベストプラクティスを実践していると、一つだけ難易度が格段に高いものがあることに気がつくでしょう。それは、『最小権限を付与する』です。最小権限には二重の意味の難しさがあります。
- 最小権限を適用するには、IAMの知識と探索の時間が必要
- 最小権限を探求するためには、IAMの権限が必要
1つ目は言わずもがなかと思います。最小権限を付与するには、IAMを正しく理解している必要があります。その上で、実際に付与する際は、ポリシーを作って実際に動かしてみてと試行錯誤が必要です。これが結構、時間が掛かります。テクニック的な面としては、大きめの権限を最初に与えておいて、後でIAMの権限の利用履歴をみて絞り込むといった方法もありますが、それでも手間が掛かるでしょう。
2つ目の探求するには、IAMの権限が必要という半ば禅問答的な問題です。最小権限を付与するためには、それ以上の権限を持っている人が実行しなければならないのです。組織的な話でいうと、ここが一番たいへんです。IAMを操作できる人を絞り込みたいし、付与する権限も最小限に抑え込みたい。でも、そうするとAWSのアカウントマネージャー的な立場の人が、ひたすらIAMの権限について考えないといけなくなります。
昔であれば、そのモデルでも何とかなったかもしれません。しかし、今だとその方式でやると破綻する可能性が高いです。なぜなら、今のAWSの設計・開発は、IAMロールと向かいあう必要があるからです。
IAMロールと向き合う
『IAMロールと向き合う』とはなんでしょうか？従来のAWSの構築は、VPCでネットワークを作ってその中にEC2をたててミドル・アプリの設計をしてという形が多かったかと思います。そのため、職能機能のAWS管理ポリシーに代表されるようなネットワーク管理者やデータベース管理者といった役割別の権限を付与して職務を遂行してもらうことになります。
今は、それに加えてAWSのマネージドサービスを活用することが多くなっています。そういった際に、何が必要でしょうか？IAMロールをひたすら作ることが必要になってきます。IAMロールを作るには、IAMの権限が必要になります。IAMの権限とは、実質的に管理者の権限です。AdministratorAccessとPowerUserAccessの違いをみると解るのですが、IAMの権限があるかないかの違いしかないのです。
という事でIAMは実質的に管理者権限で、IAMロールを作るにはその権限が必要になります。最小権限を作るために、最大の権限を渡すというこの矛盾に気が付いた瞬間に、体を引き裂かれるような思いをする事になります。
SCPとPermission Boundary
AWSもその矛盾に気が付いていて、対策となるサービスを提供しています。AWS Organizationsのサービスコントロールポリシー(SCP）と、IAMのPermission Boundaryです、どちらも似たような機能を持ち、例えIAMの権限を持っていたとしても、予め許可した範囲しか権限が有効にならなくなります。次の図のように積集合ですね。
このIAMのPermission Boundaryを使ってIAMロールは作れるけど、作れる範囲を限定するといった事ができます。詳しい手順はそのうち解説しようと思いますが、既にすばらしい解説記事があるので紹介しておきます。
ただ、このPermission Boundaryを使いこなすのが中々難しいというのもあります。IAMをちゃんと理解して、どの範囲を許可するのか、その辺りの絶妙な設計が必要になります。人類のIAMレベルを上げないと、まだまだ万人向けでないのかなぁという印象です。私も、これでいいやという答えには達してないです。
サンドボックスアカウント
もう一つの対策としては、サンドボックスアカウントという考え方があります。通常の環境と隔離したAWSアカウントを作り、その中でIAMの管理者権限を与え自由にやってもらう方法です。
隔離したアカウントといえども、アクセスキー・シークレットアクセスキーなどセキュリティ・クレデンシャルの流失で、AWSアカウントが乗っ取られたら大事故が発生します。対策としては前述のSCPなどを利用して、これだけは防ぐという動作を禁止する方法があります。
どちらも一長一短ですが、サンドボックスアカウントの方が、自由度が高く管理者の負荷は少ない傾向にあります。
そもそも『最小権限』とは？
ここまで書いていて、実はそもそも『最小権限』の定義について、何も触れていないことに気がつくかもしれません。日本人的な几帳面さで、最小権限と聞くと字面そのままに、本当の最小権限を思い浮かべていると思います。例えば、S3への書き込み権限であれば対象バケットに対しての書き込み権限のみとか、オペレーターであれば参照権限とEC2等の起動・停止の権限のみとか。
最近、ベストプラクティスの言う『最小権限』って、ここまで厳密な意味での最小権限と言っているのではないのではないかなと思えるようになってきました。例えば、開発者のそれぞれにAdmin権限渡さずに、職能機能のAWS管理ポリシーを付与するんだぞ〜的な大雑把さを指しているのではないかという気もしています。あるいは、個々のアクション単位の選定ではなく、ListやRead,Write,Permission Managementなどのアクセスレベルを指しているとか。
あまり神経質に最小権限を追求して実現できないより、ある程度の大雑把さを許容している方が、現実的には運用は回るし事故も少ないと思います。その上で、本当に気を付けないといけないS3周りのパーミッション等を厳格に定義するのが良いのではないでしょうか。
