この記事は公開されてから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ロールにフェデレートするのか
- アクセスキーが漏えいするリスクが大幅に低減される
- 既存の企業ポリシーとツールを活用する
- 新しいメンバーや辞めるメンバーに対応する
ロールの合理化とは？
リスクとアクセスニーズに基づいた役割の再設計。
プロビジョニング戦略と以前の利用状況データから、実装する候補ロールのリストを作成する。
プロセスステップ
- 現状のロールとポリシーをロールオーナーと見直す
- CloudTrailデータの収集と解析または、アクセスアドバイザーの見直しを行う
- 職位と比較する
- 現在のロール/ポリシーを改良する
- LDAPまたはIdpの割り当てを更新する
ビフォーアフター
大量のアクセス権を持ったエンジニアリングロールがほとんどのユーザーに与えられていた。
変更後は、新しい4つの細かいロールが作成された。
管理者（①IAM管理者、②脅威アナリスト）、クリエイター（③ソリューションエンジニア）、コンシュマー（④DBユーザー）
Audit time
以下のチェックを満たすことができた。
- アクセス権のある本当の人物を知っている
- ユーザー名の強制が可能
- 一貫したパスワードポリシーを設定可能
- 長期間有効なアクセスキーを排除した
- ロールはアカウントにスコープされている
- 明確に要求プロセスが定義されている
- ロールに正しいポリシーが割り当てられている
- ロールと職位がマッチしている
最後に
SID201のレポートをお届けしました。
0
