Amazon Web Services ブログ
最小権限実現への4ステップアプローチ 前編
AWS のセキュリティベストプラクティスを実現するに当たり、「最小権限の原則」に戸惑ったことはありませんか？
AWS の利用では AWS Identity and Access Management （IAM）サービスを避けて通ることは出来ません。そのベストプラクティスとして掲げられているのが、最小権限の原則です。特に強固なセキュリティを求めるユースケースではこの原則の実現が課題になることが多いかと思います。本ブログでは、この最小権限の原則をシステマチックに検討するアプローチの一例をご紹介します。
はじめに
「最小権限を適切に運用する」ことを計画する際、まず思いつくのはシステムの運用や開発の視点で「必要」となる操作の権限のみを人やアプリケーションに付与するというアプローチです。シンプルですが、権限が悪用されると組織の受容度を超えた影響をもたらしうるとして敬遠されるケースがあります。システム運用者が重要リソースへのアクセスを常用している組織などでは、「リスクを考慮して受容」できる範囲内に絞って「必要最小」の権限を人やアプリケーションに付与する形に抑制したくなることがあります。
受容可能なリスクの算出は、システム開発・運用の現場には荷の重いテーマです。検討がおざなりになって、短絡的に「少しでも危なそうな機能は使わない」とのスタンスから使いたい機能を禁止していたり、逆に「必要だから」と過剰に権限を付与していませんか。
我々プロフェッショナルサービスはこのような現場で、AWS ユーザーの皆様とともに権限の最適化を合理的に進めるアプローチを模索してきました。本ブログによりプロフェッショナルサービスが現場で養ってきたこれらのノウハウをお伝えすることで、あなたがクラウドを手の内でコントロールするための一助となればと考えています。
Tips本書は、アプローチの概要とサンプルユースケースで構成されています。概要のみ把握出来ればOKという方は、サンプルユースケースは読み飛ばしても内容を理解できるようになっています。 |
受容可能な最大権限とは
AWS は多様なユースケースに適用可能なサービスと機能を提供しています。例えば、AWS の主要なストレージサービスである Amazon Simple Storage Service （Amazon S3）は、全世界にデータを配信するプラットフォームだけではなく、機密度の高いデータを安全に保管するためのデータレポジトリとしても利用されています。お客様には、AWS のサービスや機能をユースケースに対してふさわしい構成で利用する責任があります。
機密度の高い情報を取り扱うシステムを例にとって考えてみます。そのシステムが提供するサービスにとって最も受容できないビジネス上のセキュリティリスクは、データの漏洩であるとします。Amazon S3 には前述の通りデータをパブリック公開する機能がありますから、このパブリック公開機能を有効化する権限はその組織にとっては受容しがたい権限となります。この受容しがたい権限を除いた権限が組織にとって「受容可能な権限」となります。「受容可能な権限 = S3の全権限 – パブリック公開権限」です。
システムはそんなにシンプルでないと思われるかもしれません。実際に、パブリック公開を設定する「バケットポリシーの変更権限」は多くの組織に必須の権限ですから、単純に使用禁止にすることは出来ません。本ブログでは、このような「必要だがビジネス影響を受容できない権限範囲」を特定し、統制するための権限最適化のアプローチをご紹介します（図1参照)。
なお、本ブログはプロダクション環境における権限の最適化を目的に記載しています。開発環境では開発者の利便性を最大限考慮する必要があります。機密データの取扱制限やインターネットとの限定的な接続を前提に、開発環境では本番とは別の権限セットでAWS機能を緩やかな制限で利用できるようにするケースもあります。
（図1）開発・運用者が求める必要最小限の権限と、組織が受容可能な権限の関係イメージ
権限最適化アプローチ
STEP1: 必要最小限の権限エリア（A）を把握する
まず、システム上に存在する機能とデータの一覧を作成します。AWS では、IAM の権限定義で取り扱う一連のオブジェクトがリソースと呼ばれ、これにはデータだけでなくサービスの機能も含まれます（ IAM ユーザーガイド）。
一覧ができたら、そこからリソースの相関表を作成します。多くの場合、データリソースに対して、コンピュートリソースないし人がアクセスしています。また、AWS Lambda などのコンピュートリソースに対して別のコンピュートリソースや人がアクセスすることもあるでしょう（補足1）。VPC やサブネットなどのインフラストラクチャリソースを人が作成したり変更するアクセスもあります。これらの一連のアクセスについて、アクセス元とアクセス先、アクション（補足2）を一覧化します。
一覧化のイメージはサンプルケースにてご確認ください。これがあなたのシステムにおける運用観点でリクエストされる必要最小限の権限エリアです。図1のエリア（A）にあたります。
Tipsシステムに現状割り当てられている権限は必要最小の権限ではない可能性に注意します。権限が十分に最適化されていないシステムにおいては、プリンシパルに AdministratorAccess や S3FullAccess といった、高権限の AWS 管理型ポリシーがアタッチされていることがあります。 例えば Web アプリケーションが S3FullAccess 権限を保持している場合でも、実際に利用するのは特定の Web コンテンツバケットへのReadアクセスと、ログバケットへのWriteアクセスだけという可能性もあります。対象のリソースとアクションをアンド条件で権限を特定して、付与する範囲を絞り込むことができます。 本作業を支援する AWS の機能
|
（補足1：IAM ポリシーにおけるリソースの相関関係の定義）
上記では説明をわかりやすくするためリソースがリソースにアクセスすると記載しましたが、実際にはリソースにアタッチされた IAM ロールがリソースにアクセスする形式がとられます。たとえば、Lambda Function が S3 バケットにオブジェクトを出力する場合、Lambda Function（arn:aws:lambda:us-east-2:123456789012:function:lambda-modimage）の代わりに、Lambda Function が引き受けたサービスロール（arn:aws:iam::123456789012:role/iam-role-modimage）が S3 バケット（arn:aws:s3::: s3-output-image-tsuku-lab）へアクセスするものとして認可処理が行われます。より厳密さが求められるケースでは、どのリソースがどのサービスロールを引き受けているかも可視化してロールが適切に分割されていることを確認します。AWS のリソースは Amazon リソースネーム（ARN）で一意に識別が出来ます。
（補足2：権限の検討粒度となるアクション）
IAM における権限とは、AWS のリソースや API へのアクセス許可です。人だけでなく、アプリケーションに対しても同一のメカニズムで権限が割り当てられ、AWS の機能を利用するときに評価されます。IAM ポリシーを使用してプリンシパルやリソースに付与される JSON 定義ファイルを使って、リソースの表示、作成、編集、削除など、リソースに対して実行できるオペレーション単位に権限を付与することが出来ます。このオペレーションを IAM 固有の用語でアクションと言います。最小権限を検討するに当たっては、最も細かい粒度ではアクションレベルで要否を判断することも出来ます。逆に粒度を荒くして AWS のアクセスレベル単位で要否を判断することもできます。粒度が細かい方が厳密な統制を実現できる可能性が高まる一方で、検討に時間を要します。検討にかけられるコストとシステムの重要度のバランスをみて検討の粒度を決定します。本ブログでは、アクションを AWS のアクセスレベルで記載していきます。
（補足3： AWS のアクセスレベル）
AWS の IAM では、サービスのアクションについて権限種別に相当する以下のアクセスレベル分類を定義しています。（ユーザーガイド）
AWS サービスごとに権限の名称や実装が異なるため、サービスによっては以下の例とは異なるアクセスレベルにアクションが分類されることがあります。
| AWS のアクセスレベル | 主要なアクション | 本ブログにおける表記 |
| List （リスト） | List* | L |
| Read （読み込み） | Describe*、Get* | R |
| Write （書き込み） | Create*、Delete*、Update*、Put*、Run*、Invoke* | W |
| Permissions management （アクセス権限の管理） | *Permission | P |
| Tagging （タグ付け） | *Tag | T |
サンプルケース: STEP1 必要最小権限の一覧化架空のベンチャー企業が作成した地図画像を生成するシステム「マップつくラボ」の権限最適化作業を進めてみましょう。「マップつくラボ」はポスター、広告、フライヤーに掲載する地図デザインを、実際の地図と入力パラメータを元に自動的に作成するアプリケーションです。複数のマイクロサービスを組み合わせてサービスを実現しています。S3 バケットに地図データおよびパラメータを入力情報として配置すると、パラメータに応じたオリジナルの地図を生成する商用サービスに注目して権限設計を進めてみます。システムを運用するために以下表の担当者ごとに IAM ユーザを作成します。またその画像加工処理は AWS Lambda で実施するため、Lambda 用の IAM Role を用意します。
表1 : 「マップつくラボ」システムで使用される必要最小の権限
|
|||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||
STEP2: 受容できないビジネス影響を洗い出す
STEP1 で作成した権限一覧を元に、次のステップではこれらが悪用された場合にもたらされるビジネス影響の一覧を作成します。悪用と一言にいっても内容は様々です。今回は「不正実行、改ざん、削除、持ち出し、停止」の5種類を悪用と定義して、機能やデータがそれぞれの悪用にさらされた場合のビジネス影響を評価していきましょう。
ビジネス影響は金銭価値で評価することもできますが、IT 担当であるあなたはビジネス影響を金銭価値に変換するのが得意では無いかもしれません。実際の現場で私が使用している「致命的/局所的影響/受容可」の3段階で評価するサンプルを以下にご紹介します。定量化の手法はシステムの特性によって異なります。ステークホルダーが理解しやすい形式で定義すると良いと思います。
- 本ブログで使用するビジネス影響の尺度
発生しうるビジネス影響の内容によって、尺度を定義します。本書では以下の尺度を使用しますが、組織によって調整が必要です。
| ビジネス影響のレベル | ビジネス影響の内容 | |
| Tier 1 | 致命的 | 一度の発生も許されない。短期的な回復が困難なほどに組織の業務や社会的価値を毀損する。 |
| Tier 2 | 局所的影響 | 年に数度程度なら受容可能。組織の業務や社会的価値を毀損するほどではない。 |
| Tier 3 | 受容可 | 組織への影響はなく、追加施策の範囲外とする。 |
Tipsプロフェッショナルサービスの支援で気づいたことですが、リスクの解釈はビジネスの内容によって大きく異なるようです。人材紹介サービスなどの情報自体に価値があるシステムにおいては、アプリケーションの不正実行だけでなく、情報漏洩も最もビジネス影響が大きいと分類するケースがありました。交通情報などの情報提供システムでは、公開情報を用いるため、情報漏洩によるビジネス影響は低く分類し、サービスの誤動作につながる不正実行や改ざんが最もビジネス影響が大きいと分類するケースがありました。 エンタープライズは様々なビジネスを内包していますから、同じ組織でもシステムによってリスクの解釈が異なる可能性があります。できるだけ個々のシステムに焦点を絞ってリスクを分析すると答えを得やすいと私は思います。 |
サンプルケース: STEP2 ビジネス影響検討の例「マップつくラボ」のユースケースに基づき、主な脅威とその対象となる主要機能、データ保管場所を洗い出し、ビジネス影響を確認してみましょう。
前提からエンジニア達が導き出した「マップつくラボ」にて想定される脅威とビジネス影響一覧です。 （表2：想定される脅威とビジネス影響一覧の例）
|
STEP3: 受容できないビジネス影響をもたらしうる権限範囲（B）を把握する
上記で作成したビジネス影響の一覧（表2）によって、当該システムにおいて最も防ぎたい事態が把握されました。AWS においては機能やデータ保管場所へのアクセスは各サービスのアクションに対応づけることが可能です。AWS の定義するアクセスレベルを使用して各アクションが AWS サービスのどのアクセスレベルにて発生しうるのかを整理します。組織によっては、この段階で AWS アクセスレベルではなく IAM アクション単位でビジネス影響を特定することもあります。このような細かい粒度での検討には時間がかかります。検討にかけられるコストとシステムの重要度のバランスをみて検討の粒度を決定します。
こうして作成したビジネス影響をもたらすアクセスレベルの一覧（表3-1）は、現在システムで必要とされている権限（表1）と組み合わせることで、受容できないアクセスレベルを可視化するために利用できます。また、システム運用にリクエストされる必要最小の権限とビジネス影響の一覧を整理します（表3-2）。
Tips: 脅威とアクセスレベルの関係脅威がどの権限で実行しえるかを考え、脅威とアクションの関係を求めます。以下の表は典型的な例を記載していますが、AWS サービスごとに権限の名称やアクセスレベルの割り当ては異なります。脅威とアクセスレベルの関係もサービス毎に異なる可能性があるので、最終的な権限割り当ての際に必要に応じて調整を行います。
|
サンプルケース: STEP3 受容できないビジネス影響をもたらす権限「マップつくラボ」における受容できないリスクをもたらす権限をAWSアクセスレベルで抽出してみましょう。上で作成した受容できないリスクの一覧（表2）をAWSのアクセスレベルに変換します。 （表3-1: 受容できない権限一覧）
「マップつくラボ」において、必要最小の権限が悪用された場合のビジネス影響一覧です。左側のアクセス元、アクション、アクセス先は表1から、右側のビジネス影響は表3-1からそれぞれ求めます。 （表3-2: システム運用にリクエストされる必要最小の権限と悪用された場合のビジネス影響の一覧）
|
||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||
前編では、最小権限実現のための最初の3ステップとして、必要とされる権限の中から、「受容できないビジネス影響をもたらしうる権限」を特定する方法ご紹介しました。後編では、可視化された権限の統制プランの策定ステップをご紹介します。
このブログの著者
中村 賢介（Nakamura, Kensuke）
プロフェッショナルサービス本部 シニアセキュリティコンサルタント
須田 聡（Suda, Satoru）
プロフェッショナルサービス本部 セキュリティコンサルタント