セッションタイトル: Least privilege: Move beyond default service accounts
スピーカー: Ian Lewis
なお、スピーカーのIanさんは、今年の2月の我々主催イベントで登壇いただいた方です。
Nextに登場されるようなすごい方に登壇いただき、さらに感謝！
Intro to IAM & Service Account
IAMは「誰が」、「何をできるのか」、「どのリソースで」をコントロールするものです。
クラウドでの基盤となるようなサービスです。
アカウントとしては、個人向けのユーザー、ユーザーをグルーピングしたグループ、アプリケーション向けのサービスアカウントが挙げられます。
サービスアカウント
以下のような特徴を持ちます。
- メールアドレスで識別
- 簡単にアタッチ
- アカウントキーで認証可能
ロールとパーミッション
別のセッションでも触れられてましたが、Basic権限には非常に多くのパーミッションが付与されています。
過剰な権限は多くのセキュリティリスクを伴ってしまいます。
Default Service Account
Default Service Accountには以下のような特徴が挙げられます。
- 自動的に割り当てられる
- 簡単に始めるには便利
- だいたい権限過剰
- デプロイサービスでしばしば過剰権限
「Default Compute Service Account」や「Cloud Build Service Account」などがあります。
最小権限の原則
「それぞれのシステムはそのシステムの仕事に合わせて、必要なパーミッションのみを持つべきである」と言った意味合いです。
Blast Radiusの制限や、ラテラルムーブメントの抑止の効果があります。
「Blast Radius」とは直訳すると爆発範囲のような意味で、ここではセキュリティ攻撃を受けた場合の被害範囲になります。
Practical Attacks
実践的な攻撃事例のご紹介です。
こちらは、以前に別のブログでも紹介させていただいたものになります。
Customer Service Account & Roles
セキュアにサービスアカウントを利用するにはカスタムで作成しましょう。
- 目的ごとに作成
- ロールもカスタムで
- 最小権限に
自動的な最小権限
組織ポリシー
以下のようなガードレール構築に有効です。
- 特定のリソース作成を抑止
- フォルダなど階層リソースの利用
- セキュリティベースラインの徹底に有効
例としては以下のようなものが挙げられます。
Cloud Security Command Center (CSCC)
以下のような活用ができます。
- IAMレコメンデーションのレビュー
- AIによる検出事項のサマライズ
- PubSubを使った検出事項の自動修復
Policy Analyzer
適切な プリンシパル、ロール、パーミッションにマッチするよう、IAMポリシーをクエリできます。
結果を出力して解析します。
まとめ
サービスを試用してみるときなどに、サッと利用できるデフォルトサービスアカウントは非常に便利ですが、本番環境で使い続けるには多くのリスクを伴います。
カスタムで作成して、最小権限による利用に切り替えていきましょう！
