[レポート]デジタルトランスフォーメーション（DX）の成功を支える権限管理　AWS-40 #AWSSummit

こんにちは、AWS事業本部@福岡オフィスのべこみん(@beco_minn)です。

2023年4月20日〜21日に開催されているAWS Summit Tokyo 2023、皆さん参加してますか？

本記事はAWS Summit Tokyoで行われたセッション「AWS-40 デジタルトランスフォーメーション（DX）の成功を支える権限管理」のセッションレポートです。

セッション概要

デジタルトランスフォーメーション（DX）の成功を支える権限管理

デジタルトランスフォーメーション（DX）の成功のために、煩雑な従来のセキュリティアプローチのアップデートが必要です。セキュリティリーダーは、チームが限られた時間を最も価値の高いタスクに費やせるように、そして組織のスピードとイノベーションのニーズを加速させるために取り組みます。 本セッションでは、権限管理に焦点を当て、セキュリティとスピードを犠牲にしないモダンな考え方、サービスや機能の活用を解説します。AWS のサービスや機能をフル活用することで、自信を持ってクラウドのセキュリティを「シフト」しましょう。

オンデマンド配信

AWS Summit Tokyo 2023のセッションの多くは下記期間でオンデマンド配信されています。

2023年5月22日12:00 〜 2023年6月23日19:00

オンデマンド配信をご視聴するためには下記ページよりご登録していただく必要があります。

登録済みの方は、本セッションのオンデマンド配信を下記URLにてご覧いただけます。

https://jpsummit.awsevents.com/public/session/view/559

登壇者

アマゾン ウェブ サービス ジャパン合同会社
技術統括本部
シニアセキュリティソリューションアーキテクト

中島 智広 氏

レポート簡単まとめ

• DXの成功を支える権限管理の在り方
  • ビジネスの成長にはセキュリティが重要。特に開発者の動きを阻害しないような権限管理が必要。
• 権限管理のモダナイズへの取り組み方、勘所
  • モダンな権限管理はガードレール型
    • マルチアカウントアーキテクチャが有効
  • 組織におけるグランドデザインを進める
• 有用なAWSのサービスや機能、使い方
  • マルチアカウントアーキテクチャ
    • AWS Organization
    • AWS Control Tower
  • データ境界、アクセス許可の境界、アクセス権限セット
    • IAMやIAM Identity Centerを使う

レポート

アジェンダ

• DXにおける権限管理の重要性
• モダンな権限管理の考え方
• 組織におけるグランドデザインの進め方
• AWSにおける権限管理のスタートポイント
• DXにおける頻出論点と打ち手
• おわりに

DXにおける権限管理の重要性

組織のスピードとイノベーションのニーズを加速するためには、「開発や運用の俊敏性/利便性」と「セキュリティの確保」を限られた時間の中でやる必要がある。

従来の煩雑な方法でそれを行うのは難しいため、AWSの機能をフル活用&シフトレフト（※）することでセキュリティを改善しよう！
※ セキュリティ対策を工程の頭（左側）に持ってくること

そのセキュリティ対策の中でも重要なトピックの1つが権限管理

権限管理をモダナイズし、開発者や運用者が必要とする権限を迅速に制限しよう。

モダンな権限管理の考え方

モダンな権限管理とは？

• ガードレール型
  • リスクをコントロールしながらより多くの権限を与える方法
  • 従来はゲートキーパー型。必要に応じて都度承認を得ていた。
  • 許可リスト型から禁止リスト型への移行を意図するわけではない

ガードレール型の考え方は「深刻な事故に至る蓋然性（※）を実質的に無くす」というもの
※ 実際に起こるか否か、確実性の度合い。「多分、おそらく」ぐらいの確度。

このガードレールを複数のポイントで多層的に配置するのが良い

• 組織外への持ち出しなど、重大な事故に繋がるものは厳密に予防
• 許容可能な範囲で柔軟性を提供
• 職務や業務によって管理ポイントを分掌

組織におけるグランドデザインの進め方

グランドデザインの標準化の必要性

• グランドデザインとは？
  • 組織における合意形成
    • セキュリティアプローチのアップデートには非技術者を含む組織の関係者の理解と安心感が欠かせない
  • 確実な運用
    • 何をどのように使って実装するべきかを可視化
    • メンバーの理解を助け、運用を安定
• グランドデザインで整理するもの
  • 職務と業務の分掌
    • 何を管理、担当する職務なのか？
    • どのような責任を持つか？
    • 必要な知識、スキルは？
  • アーキテクチャ
    • AWSのどのサービスを使うか？
    • どのような単位でAWSリソースを管理/統制するか？

良いグランドデザインには、技術者、非技術者のどちらも欠けてはいけない。決める際には両方のリーダーをアサイン、あるいは協力者を得ることが大事。

AWSにおける権限管理のスタートポイント

まずは組織にモダンな考え方を取り入れるため、制約の所在やキーパーソンを特定する。

次に、アーキテクチャを検討する。

今日のAWSでは、権限分離のためにマルチアカウントアーキテクチャを使うことがベストプラクティスになっている。

以下のような単位で「AWSアカウント」そのものを分離する

• アカウント統制（親アカウントのようなもの）
  • 本番
  • 開発
  • セキュリティ
  • 運用管理

なぜAWSアカウントを分離するのか？

• AWSアカウントは理想的な環境分離の単位
• AWSアカウントごとの独立した権限管理が可能。リソースグループの明示的な境界もある。
• 分離そのものがガードレールとして機能する

分離を確実にするためのベストプラクティス例

• 開発はテストデータの利用を徹底する
• 本番データを利用したテストのための環境やプロセスを設ける
• 本番環境のデータが必要な場合はプロセスを設ける（クレンジング、マスキングなど）

マルチアカウントアーキテクチャを実現するサービスは下記

• AWS Organization
  • 複数のAWSアカウントを効率よく統制するためのマネージドサービス
• AWS Control Tower
  • プリセットとして提供されるコントロールにより管理者のガードレール運用をサポート
  • 東京、大阪リージョン共に利用可能

最近ではAWSパートナーでも上記サービスを取り扱っているので、付き合いのあるAWSパートナーへ相談してみましょう！

DXにおける頻出論点と打ち手

• 頻出論点
  • データへの円滑なアクセスと保護
    • データ境界（Data Perimeter）
  • クラウドネイティブ開発
    • アクセス許可の境界（Permissions Boundary）
  • 権限管理オペレーションの効率化
    • アクセス権限セットの共通化

データ境界（Data Perimeter）

データ保護のために、信頼できるアイデンティティのみが、期待されるネットワークから信頼できるリソースにアクセスすることを確実にする予防的な一連のガードレール

主要なAWS上のサービス（ツール）は以下

• リソースベースポリシー
  • 例: aws:PrincipalOrgPaths という条件キーで定めたアカウント群以外からのアクセスを防止可能
• サービスコントロールポリシー（SCP）
  • 例: aws:ResourceOrgPaths という条件キーで定めたアカウント群以外からのアクセスを防止可能
• VPCエンドポイントポリシー
  • 例: aws:ResourceOrgPaths という条件キーで定めたアカウント群以外からのアクセスを防止可能

他にも様々な条件キーがある。

データ境界についてより詳細な情報が欲しい人は、下記のホワイトペーパーやサンプル集、ワークショップを参照して欲しい。

• Building a Data Perimeter on AWS - Building A Data Perimeter on AWS
• GitHub aws-samples/data-perimeter-policy-examples
• Data Perimeter Workshop

アクセス許可の境界（Permissions Boundary）

クラウドネイティブ開発にはIAM権限が必要

ポリシーを作成し、IAMロールを作成し、そのロールをAWSリソースに割り当てる

開発者へのIAM権限の委譲に望ましい統制は下記

開発者が作成するロールの権限 <= 開発者の権限

つまり、権限昇格を防止することが大事

アクセス許可の境界ポリシー iam:PermissionsBoundary を用いることで、管理者が設定するポリシーと開発者が設定するポリシーの両方で許可されている権限のみ行使可能という設定が可能

また、iam:DeleteUserPermissionsBoundary を使うことで無効化や変更を禁止することも可能

上記を設定するサービスは

• AWS IAM
• AWS IAM Identity Center（旧AWS SSO）

また、アクセス許可の境界は基本的に開発環境に実装するのが好ましい。本番環境ではそもそも開発者による頻繁な変更は必要とならないはず。

アクセス許可の境界についてより詳細な情報が欲しい人は、下記のホワイトペーパーやサンプル集、ワークショップを参照して欲しい。

• IAM エンティティのアクセス許可境界 - AWS Identity and Access Management
• GitHub aws-samples/example-permissions-boundary

参考：魔法のPermissions Boundary | AWS（PDFリンク）

アクセス権限セットの共通化

なぜアクセス権限セットを共通化するのか？

• 可視性・運用性の担保
  • 最小権限の原則や抽象的なルールに基づく属人的な権限付与は運用が難しい
• ガードレール型の権限管理
  • ガードレールの整備が進むと、割り当て可能な権限は職務や業務ごとに共通的になる

上記を行うためにIAM Identity Centerを使おう

• AWS IAM Identity Center
  • 管理者は同一のAWS Organizationsに属するAWSアカウントに対し、誰がどのような権限でアクセスできるかを一元管理できる
  • 開発者は複数の権限をクイックに切り替えて各々のAWSアカウントにアクセスできる

おわりに

• セキュリティはビジネスの成長を支えるもの
• 優れたブレーキがあるからこそ、安心してアクセルを踏んで目的地を目指すことが出来る
• AWSサービスをフル活用し、自身を持ってクラウドのセキュリティを「シフト」しよう

最後に（感想）

本セッションでは今日有効な権限管理を学ぶことが出来ました。

セキュリティを組織に導入するためには技術者だけでなく非技術者の協力も必要、まさに「サイバーセキュリティは全員参加」ですね。グランドデザインという言葉を私は初めて聞きましたが、意図は非常に伝わりました。

私も「セキュリティはビジネスの成長を支えるもの」という意識を常に持って、これからもセキュリティ導入の支援を行っていこうと改めて気持ちを引き締めました。

本記事がどなたかのお役に立てれば幸いです。

以上、べこみんでした。