【レポート】 SID201 – エンタープライズでのIAM: バンガードはいかにして、アジリリティ、ガバナンスとセキュリティのバランスを両立させたか #reinvent #sec201

この記事は公開されてから1年以上経過しています。情報が古い可能性がありますので、ご注意ください。

はじめに

re:Invent 2017の「SID201 - エンタープライズでのIAM:バンガードはいかにして、アジリリティ、ガバナンスとセキュリティのバランスを両立させたか」を聴講したのでレポートします。
講演者は、AWSのReef Dsouzaさんと バンガードのRajeev Sharmaさんです。
前半はReefさん、後半はRajeevさんの発表でした。

原題は、「SID201 - IAM for Enterprises: How Vanguard Strikes the Balance Between Agility, Governance, and Security」です。

セッション概要

バンガードにとって、AWSのアイデンティティとアクセス管理(IAM)オブジェクトの作成を管理することは、開発者の速度とコンプライアンスのバランスをとるためのキーです。
このセッションでは、バンガードがIAMの役割をどのように設計してAWSリソースの爆発的な範囲を制御し、開発者にとってシンプルさを維持するかを学びます。 また、ガバナンスを管理し、AWSリソース全体の可視性を向上させるベストプラクティスを共有します。

レポート

エンタープライズセキュリティの目的地

  • 徹底した防御
  • 職務の分離
  • 最小権限の原則に従う

分離のためにAWSアカウントを利用する

セキュリティ境界
アカウント内のユーザーとデータを分離する。
そのアカウントのセキュリティポリシーに従い、影響範囲を小さくする。

リソースの封じ込め
アカウント内で作成されたリソースはその特定のアカウントに制限される。
AWSリソースは、アカウントごとにハード制限とソフト制限によって制約される。

財務コントロール
請求および財務詳細は、アカウントごとに定義および管理される。

IAMとコアコンポーネント

ユーザ、グループ、ロール、ポリシー。
ポリシーはJSONで書かれたアクセス情報。

AWSのIDフェデレーション

IDフェデレーションを使う前では、ユニークな認証情報、長期間有効なキーがある。
IDフェデレーションを使うと、シングルサインオンや一時的なトークンを利用できる。

スケールにおける試練

  • 多くのAWSアカウント
  • 多くのユーザー
  • 多くのIAMロール
  • 適切なリソース権限の粒度
  • トレサビリティ
  • Idpが利用できない?

バンガードについて

バンガードは世界最大の投資会社の1つで、低コストの投資信託、ETF、アドバイス、および関連サービスを幅広く提供する。
すべての投資家のための立場を取って公平に扱い、投資成功のための最良のチャンスを与えることを目的にしている。

信頼のできる情報源

  • CIS AWS Foundations
    • 実際の脅威に対してシステムを強化するベンチマーク
  • NIST 800-53
    • 米国の政府機関のセキュリティ管理に利用される
  • SOC 2
    • セキュリティ、可用性、および処理の整合性に関連するサービス組織のコントロールについて記載されている
  • GS007
    • オーストラリアの政府監査と保証のスタンダードボード
  • バンガードの内部セキュリティポリシー

コンプライアンス要件

  • ワークフロー
    • アクセスが自動的に提供されること
  • クレデンシャル管理
    • パスワードおよびログインパラメーターが、企業ポリシーと手順に従って設定されること
  • ガバナンス
    • ユーザーアクセスが調整されていること
    • ユーザーアクセスが管理者によって、半年ごとにレビューされていること

IAMユーザーを各々のAWSアカウントに作成した場合

長期間有効なキー、MFAトークン、パスワードが多数作成され管理が難しい。

最初の役割管理

ユーザーがロールをリクエストすると、ロールオーナーは承認するか判断する。
承認された場合、LDAPを更新する。
リクエストはアーカイブされ、監査に利用される。
SAMLやSTSのようなフェデレーションを利用する。

なぜIAMロールにフェデレートするのか

  • アクセスキーが漏えいするリスクが大幅に低減される
  • 既存の企業ポリシーとツールを活用する
  • 新しいメンバーや辞めるメンバーに対応する

ロールの合理化とは?

リスクとアクセスニーズに基づいた役割の再設計。
プロビジョニング戦略と以前の利用状況データから、実装する候補ロールのリストを作成する。

プロセスステップ

  1. 現状のロールとポリシーをロールオーナーと見直す
  2. CloudTrailデータの収集と解析または、アクセスアドバイザーの見直しを行う
  3. 職位と比較する
  4. 現在のロール/ポリシーを改良する
  5. LDAPまたはIdpの割り当てを更新する

ビフォーアフター

大量のアクセス権を持ったエンジニアリングロールがほとんどのユーザーに与えられていた。
変更後は、新しい4つの細かいロールが作成された。
管理者(①IAM管理者、②脅威アナリスト)、クリエイター(③ソリューションエンジニア)、コンシュマー(④DBユーザー)

Audit time

以下のチェックを満たすことができた。

  • アクセス権のある本当の人物を知っている
  • ユーザー名の強制が可能
  • 一貫したパスワードポリシーを設定可能
  • 長期間有効なアクセスキーを排除した
  • ロールはアカウントにスコープされている
  • 明確に要求プロセスが定義されている
  • ロールに正しいポリシーが割り当てられている
  • ロールと職位がマッチしている

最後に

SID201のレポートをお届けしました。