AWS のセキュリティベストプラクティスを実現するに当たり、「最小権限の原則」に戸惑ったことはありませんか？

AWS の利用では AWS Identity and Access Management (IAM) サービスを避けて通ることは出来ません。そのベストプラクティスとして掲げられているのが、最小権限の原則です。特に強固なセキュリティを求めるユースケースではこの原則の実現が課題になることが多いかと思います。本ブログでは、この最小権限の原則をシステマチックに検討するアプローチの一例をご紹介します。

前編では、システムが必要とする権限と、そこに内在する「受容できないビジネス影響をもたらしうる権限」を可視化する方法を3つのステップでご紹介しました。後編である今回は、前編で可視化した権限について統制のメカニズムを計画するプロセスをご紹介します。まだ前編をお読みでなければ、ぜひそちらもご活用下さい。

STEP4: 受容できないビジネス影響をもたらしうる権限範囲（B）の統制メカニズムを選定する

これまでのステップで、システム運用にリクエストされる必要最小限の権限エリア（A）と、組織にとって受容できないビジネス影響をもたらしうる権限エリア（B）が可視化されました。単純に後者の権限エリアを使用禁止にすることも出来ますが、その解決方法では主要な AWS 機能が利用出来ず、機能不全に陥る可能性があります。ビジネス影響をもたらしうる権限範囲（B）が、通常利用においても必要不可欠な権限の一部であることがあるからです。

例えば Lambda 関数は VPC 外で実行すると、VPC の制御を経ずにパブリックネットワークとデータを送受信出来てしまいますが、単純に Lambda 自体を禁止してしまうと Lambda と密に連携した様々な AWS サービスの利活用に制約が生まれてしまいます。

これらの不都合を合理的に解消し、クラウドの価値をできるだけ生かしつつ受容できないビジネス影響を抑制するためのアプローチが複数あります。これらからふさわしい方法を使い分けて、最終的にプリンシパルに割り当てる権限を決定します。

今回は我々がベストプラクティスと考えている5つの手法をご紹介したいと思います。

手法1 権限を条件で細かく制御する

強固なセキュリティを守る上でまず第一に議論されるのが受容できないビジネス影響をもたらしうる権限範囲（B）を厳密に除去し、受容可能最大ラインを超える権限は使用を禁止するというものです。厳にこれを実装した場合、ビジネス影響を伴う機能は使用できなくなってしまいます。これを避けるため、条件付きポリシーを使用して受容できないビジネス影響をもたらしうる権限だけを部分的に禁止するよう制御します。

先の VPC 外 Lambda の例なら、Lambda 関数の作成に VPC 条件を付与することで、VPC の NW 制御を受けない Lambda 関数の使用を制限することが出来ます。

{
  "Version": "2012-10-17",
  "Statement": [
    {
      "Sid": "EnforceVPCFunction",
      "Action": [
          "lambda:CreateFunction",
          "lambda:UpdateFunctionConfiguration"
       ],
      "Effect": "Deny",
      "Resource": "*",
      "Condition": {
        "Null": {
           "lambda:VpcIds": "true"
        }
      }
    }
  ]
}

手法2 データに対する人の直接アクセスを抑制する

データへの手動アクセスを排除するメカニズムとツールを使用します。これにより、機密性の高いデータを扱う際の誤処理、改変、ヒューマンエラーのリスクを軽減します。

具体的にはアプリケーションや CICD パイプラインが使用する IAM ロールに受容できないビジネス影響のある権限範囲（B）の権限を限定して付与し、開発者や管理者に対しては（B）の権限は付与しない様に実装します。

手法3 事前定義型の機能を使用する（AWS Control Tower による予防的ガードレール）

機能は利用しつつ、受容できないビジネス影響を排除するアプローチがあります。我々が予防的ガードレールと読んでいる考え方では、その組織が受容可能なパラメータに調整された形で機能を払い出し、開発者やアプリケーションは、安全な状態にプリセットされた機能しか利用できないように統制します。

ガードレールを構築する要員は統制を破壊する権限を持ちうるので、彼らによる不正が発生しないような統制メカニズムが別途必要になります。AWS が提供するマネージド型のガードレール機能である AWS Control Tower では、ガードレールの生成を自動化することで要員による統制の逸脱を抑制するメカニズムを形成しています。AWS Control Tower が提供する機能セットは限定的ですが、これを拡張してあなたのシステムにふさわしいガードレールを作成することも出来ます。

また、もう少し限定的な保護アプローチとして、追加の保護レイヤーをもうけて単一の権限ではビジネス影響の大きい事象を発生させられないようにする手法をとることも出来ます。

• 追加の保護レイヤーの代表格が暗号化です。Amazon S3 などのサービスでは、単一の防御が危殆化しても、暗号化レイヤーでデータが保護されるように構成することができます。
• Amazon S3 のパブリック公開に関しては、パブリックアクセスブロック機能が利用できます。パブリックアクセスブロック機能をアカウント単位で有効化しておくことで、個別のバケットポリシーや ACL によるパブリック公開を禁止できます。
• NW も代表的な保護レイヤーの一つです。VPC の内部にリソースを集約し、VPC の機能でリソースを保護することで、権限によって保護する範囲を絞り易くなります。

（使用可能なAWSサービスと機能、AWS Control Tower / AWS Organizations / IAM Permission boundary / AWS Key Management Service / Amazon VPC）

手法4 権限の行使を監視する（発見的ガードレール）

受容できないビジネス影響をもたらしうる権限の行使を監視するという手法があります。先の Amazon S3 の例でいえば、バケットポリシーを監視し、承認されていないものは検出、対処をするというものです。このアプローチは望まない構成変更イベントなどを監視するために用いられます。

データイベントはイベント数が多いことなどからそもそも監視負担が大きくなりがちですが、対象によっては Amazon GuardDuty を使用することで負担を軽減できるケースもあります。また、データ系イベントでは、API 実行が検知された段階でデータの移動が完了しているケースもあるので、API 実行を監視しても望まぬデータフローを未然に防ぐことは完全にはできません。他の統制手法と発見的ガードレールを組み合わせて利用することで、統制メカニズムを合理化します。

また、証跡を広く取得することで、内部犯行を自重させるという穏やかな統制をとることも可能です。クラウド上におけるさまざまな権限実行やデータフローについて証跡を取得し、管理者であっても証跡の完全性を毀損しないように構成することが出来ます。証跡が完全に取得、維持され、何かあれば実行者が特定されるとすべての管理者に周知されることが重要です。監視カメラの目の前で泥棒をする人は、顔を隠していますよね。もし顔を隠せなかったら彼らは犯行に及ばなかったかもしれません。

（使用可能な AWS サービス、AWS Security Hub / AWS Config / Amazon EventBridge / Amazon GuardDuty）

手法5 非準拠のリソースを自動修正する（訂正的統制）

前述の発見的ガードレールをさらに拡張し、問題のあるリソースを自動で修正するという実装も可能です。前述の Amazon S3 の例であればパブリック許可をもったバケットポリシーが検出されたら、いったんバケットポリシーを全アクセス禁止の形式に上書きしてしまうというアプローチです。予防的な統制が選択できない場合には現実的な選択肢になります。

（使用可能な AWS サービスや機能、AWS Config Rules / AWS Systems Manager Automation documents）

最後に

本ブログでは、高度なセキュリティ要求を持つ現場で活用できる権限最小化の 4STEP アプローチと、受容できないビジネス影響をもたらしうる権限を安全にコントロールするための5つの手法をご紹介しました。

IT システムのすべての要素を完璧にセキュアにすることは難しい目標です。ゼロデイの脆弱性が標的にされる事例も目にします。システムやアプリケーションに部分的な瑕疵があっても、全体としてセキュリティが担保される枠組みが求められています。開発者がIT革新を生み出すためには、できる限り制限のない権限セットが求められます。組織のリスク受容度を高め、リスクをもたらす可能性のある権限であってもリスク低減策を講じて安全に利用する努力が必要です。

プロフェッショナルサービスでは権限のチューニングや、プレイブックの整備など、クラウドの安全な利用ノウハウを様々なお客様とともに育んでいます。今後も様々な形で皆様の IT 革新をご支援していきますのでご期待ください。

参考リンク

IAM ポリシーの具体的な記述テクニックについては公式ブログでも紹介しています。こちらもあわせてご活用下さい。

Techniques for writing least privilege IAM policies

このブログの著者

中村 賢介（Nakamura, Kensuke）
プロフェッショナルサービス本部　シニアセキュリティコンサルタント

 
 
 
 
須田 聡（Suda, Satoru）
プロフェッショナルサービス本部　セキュリティコンサルタント