この記事は公開されてから1年以上経過しています。情報が古い可能性がありますので、ご注意ください。
こんにちは、虎塚です。
re:Invent 2015で「SEC312 - Reliable Design and Deployment of Security and Compliance（日本語タイトル: 信頼性の高い設計と、セキュリティおよびコンプライアンスのデプロイ）」を聴講したので、レポートします。
テーマは、AWS環境での設計をセキュアにおこなう方法についてです。発表されたのは、Chad WoolfさんとTim Sandageさんでした。AWSでリスク/コンプライアンス戦略のお仕事をされている方のようです。
このセッションについて
- 監査やガバナンス担当者のためのテクニカルセッションです
- テクニックはどんどん変化します。政府の法制によって変化することもあります。そんな中で、AWSサービス全体のセキュリティをどのように考えればよいかを紹介します。
- 「設計によるセキュリティ (Security by Design)」アプローチ: AWSをセキュアに使い倒します
- これらのコンセプトに基づいて、キーとなるリソースを利用したライブデモをおこないます
起きるかどうかではなく「いつ」起きるかだ
規制・監査されたセンシティブなデータは、今後ますますクラウドで適切に保存され、処理されるようになります。
これは、Chad Woolfさんが昨年のre:Inven2014で発表したスライドの最後で述べた言葉です。実際、この1年間で環境の自動化やセキュリティの自動化はますます重要視されるようになりました。
AWSクラウドは高度なガバナンスを提供する
5〜10年前の手動で監査が可能だった世界と、現在の複雑な世界を比較してみましょう。
| シンプルな世界での手動監査 | 複雑な世界でのガバナンス |
|---|---|
| 分厚い実施マニュアル | ソフトウェアによって守られたプロセス |
| 定期的な調査 | アラーム/トリガー |
| ほとんど信用ならない自動制御 | ユビキタスでソフトウェアドリブンで事前に予測可能な制御 |
| （できれば）サンプルをテストすること | 母集団全体の監視と、そのうち1つのテスト |
新しいものが登場するにつれて、世界はより複雑化しています。そのため、より信頼性の高いオペレーションが必要になっています。
AWSでのコンプライアンスの発展
FIPS、ISO、SOC、ITARなど、政府からさまざまな種類の認証が出ています。これらについては、AWSのホワイトペーパーやベストプラクティスで触れられていますし、顧客事例もAWSのサイトでたくさん公開されています。
AWSでのコンプライアンスの評価
このセッションで紹介する**Security by Design (SbD) **のテクニックは、(1)AWSの認証、(2)顧客によるドキュメント利用、(3)顧客事例からの学習、のさらに次のステップで必要になります。
SbDを実践することで、コンプライアンスの維持について、顧客にデモンストレーションを見せることができるようになります。
Quality by Design (QbD)
SbDの考え方は特に新しくありません。自動車産業などの分野で使われてきたQuality by Designという一般的な考え方が元にあります。2013年にFDAが強く推奨しました。
Quality by Designは、プロダクトデザインの標準化、手動テストの自動化、トラブルシューティングの流れに関する科学的なアプローチです。QbDは、最終段階のプロダクトテストに頼る代わりに、開発プロセス全体を通して上流の観点を提供する、品質保証のためのシステマティックなアプローチです。
Security by Design (SbD)
SbDもQbDと同じ考え方です。SbDは、事後監査の代わりに、IT管理プロセス全体にわたるコントロールの観点を提供する、セキュリティ保証のためのシステマティックなアプローチです。サンプルベースであったり、AWS環境の設計の内側から監査を実現したりします。
SbDでは、golden environmentという考え方が基本になっています。単なるgold imageではなく、セキュリティ管理に関するすべてを考慮したgolden environmentを作ることについて説明します。golden environmentには、たとえば、ネットワーク設定、リソースのロギング、パーミッションの作成、暗号化の強制などが含まれます。AWS環境でのスクリプティングによって、これらを実現します。
Security by Designは、現代的なセキュリティ保証のアプローチです。SbDでは、AWSアカウント設計、セキュリティ制御の自動化、監査の合理化をおこないます。さまざまな観点から眺めることで、AWSアカウント全体で何が起きているかを検査します。
Security by Designのインパクト
SbDは、あなたが現在たくさんの分厚いマニュアルや手続きで実施しているITガバナンスのポリシーを、スクリプトに置き換えます。SbDの成果物は、高い信頼性をもつコントロールの実装です。
セキュアなアーキテクチャの要素
golden environmentに必要な要素を見てみましょう。
- CloudFormationテンプレートを使用してgolden environmentを作ること
- AWS Service Catalogの利用を強制して、誰がどんなアプリケーションスタックを利用できるかを制御すること
- AWSサービスにアクセスさせるためのパーミッションを作成すること
golden code: AWSでのセキュリティ設定
あらゆるIT環境に必要とされる定義は、次のとおりです。CloudFormationテンプレートでは、これらをJSONで記述します。
- ファイアウォールルール
- Network ACL
- サーバへのタイムポインター
- 内側 (private) または外側 (public) のサブネット
- NATルール
- Gold OSイメージ
- 転送/保存するデータの暗号化アルゴリズム
1. golden environmentの作成
まず、gold OSイメージを作ります。次に、AWSサービスの使用について設定をおこないます。設定の例を次に示します。
- Amazon S3
- SSE (Server Side Encryption) の強制
- ログ取得の有効化
- 保持の設定
- Amazon Glacierへのアーカイブの設定
- 外部からのアクセスの禁止
- オーバーライドするパーミションの制限
- event notificationの設定
- Amazon EBS
- ボリュームタイプの定義
- ボリュームサイズの制限
- IOPSパフォーマンス (I/O) の設定
- データのロケーション (リージョン)
- スナップショット (バックアップ) ID
- データ暗号化の要件
- Amazon Redshift
- クラスタタイプ (シングル or マルチ)
- 暗号化 (KMS or HSM)
- VPCのロケーション
- 外部からのアクセス (許可/拒否)
- セキュリティグループの適用
- SNSトピックの作成
- CloudWatchアラームの強制
デモ: GUIからS3の設定をする
まず、CloudTrailのログ格納バケットに対して、S3バケットのログを有効化する設定をします。
次に、ライフサイクルの設定をします。retention ruleで、ログを生成から30日残す設定をするとともに、生成から60日でGlacierへアーカイブする設定をし、425日で期限切れになる設定をします。
それから、過去バージョンに対する設定をします。過去バージョンになってから30日でinfrequent accessストレージにいくように、60日でGlacierにアーカイブするように、そして425日で完全に削除されるように設定します。
最後に、S3のタグの設定をします。タグ付けは、キーへのアクセスが支払いにどう影響するかを理解するために重要です。
これで完了です。この設定を、AWSアカウントにあるすべてのS3バケットに対して実施します。
1. golden environmentの作成（つづき）
SNS、CloudTrail、S3のテンプレートでは、次のような設定をおこないます。
- SNS topicの作成
- CloudTrail用のS3バケットの作成
- CloudTrailログのためのS3バケットのログ取得を有効化
- SNS通知を設定
- CloudTrailのS3バケットに対するセキュリティ設定
ヘルプドキュメント
golden environmentを作るにあたっては、次の資料が参考になるでしょう。
- AWS Security Best Practices
- AWSソリューションアーキテクトやAWSプロフェッショナルサービス
- AWSパートナー
- Introduction to AWS GoldBase
2. AWS Service Catalogを強制する
管理者は、承認されたリソース（product）カタログを作成し、管理します。個人用にカスタマイズされたポータルを通して、エンドユーザはカタログにアクセスできます。これによって、管理者によって承認されたリソースだけを、エンドユーザに利用させることができます。
AWS Service Catalogのproductは、AWS CloudFormationテンプレートでデプロイできます。
デモ: AWS Service Catalog
secure network baseline templateを作るデモが行われました。
- Service Catalogでproduct一覧を表示します
- デモでは、Network Stack, Resources Stack, Access Stack, Main Stack, Application Stackの5つの環境が表示されています
- これらの各環境は、CloudFormationテンプレートで作成されたスタックです
- portfolioからproductを作成して、環境を作成します
- portfolioには特定のAMI、設定などの制約を持たせて、サブネットやサブネットのルールを定義できます
- パーミッションを作成します
- 誰が環境をデプロイできるかを定義します
- 他のAWSアカウントからクロスアカウントで操作させることもできます
- タグをつけます
- 隔離した環境で保護すべきデータを特定するため、タグ付けを強制することができます
3. AWSを利用させるためのパーミッションの作成
AWS Service Catalogでは、あるユーザにCloudFormationテンプレートのデプロイだけをさせて、ほかの操作を許可しないパーミッションを与えることができます。
デモ: IAMでパーミッションを定義する
IAM User, Group, Roleは、セキュリティの一般的な管理フレームワークです。たとえば、Read OnlyのAdminIAMRole、CloudTrailのRole, InstanceOperationのRole、SystemAdministratorのIAMRoleなどカスタマイズしたRoleを定義できます。組織の運用ポリシーや手順に沿ってカスタマイズするとよいでしょう。
ここでもう一度、Security by Designがもたらすものについて振り返っておきましょう。
SbDによって、あなたのガバナンスポリシーをスクリプト化して、信頼性の高いコントロールの実装を手に入れましょう。
その他のサービス/ツール
AWS Config Rules
AWS Config Rulesはパワフルなツールです。既存の環境にデプロイされたセキュリティデザインを、事前にAWS Lambdaで定義したルールで包括的にチェックできます。
精確で完全な監査が可能です。ReadOnlyアクセス権だけで、すべての環境を監査するためのルールを設定することができます。定期的なチェックも可能で、たとえば過去6ヶ月にAWSリソースに何が起きたかをチェックすることができます。
- 関連セッション: SEC314 - AWS Configを用いて全ての可視化と継続的なモニタリングに移行する
AWS Inspector
新サービスのAmazon Inspectorは、in-hostのコンプライアンス管理ツールです。OS、ネットワーク設定、アプリケーション設定などについて、自動でインスペクションを実施できます。
- 関連セッション: SEC324 - 新機能! Amazon Inspectorの紹介
SbD: IT GRC (ガバナンス、リスク、コンプライアンス)
AWSが提供しているガバナンス、リスク、コンプライアンスに関するサービスをまとめます。
- 正しいSecurity by Designのテクノロジー
- Security by Designに関するホワイトペーパー
- AWS GoldBase
- AWS Config Rules: 監査
- AWS Inspector: 高度なin-hostのセキュリティ維持と監査
- AWS提供のトレーニング
GoldBaseは、セキュリティ管理の実装のマトリックス、アーキテクチャ図、各種基準に則ったCloudFormationテンプレート、ユーザーガイドとデプロイインストラクションから構成されています。
Getting started
セッションの内容をあなたの環境に適用するには、次のコンテンツから始めてください。
- Introduction of AWS Security by Design
- AWS GoldBase Implementation Guide
- アーキテクチャ監査のセルフトレーニング QuickLab ($27)
- アーキテクチャ監査: 6時間のインストラクション（AWSまたはパートナーが提供）
- 連絡先: awsaudittraining@amazon.com
- re:Invent 2015の関連セッション
- SEC302 - 生き延びるためのIAMベストプラクティス
- SEC324 - 新機能！Amazon Inspctorの紹介
- SEC305 - 60分以内にAWS IAM Policyエキスパート(忍者)になろう
- SEC314 - AWS Configを用いて全ての可視化と継続的なモニタリングに移行する
感想
セッションは以上でした。Gold Imageについては昔からいわれていましたが、今ではより包括的で抽象度の高い概念としてgolden environmentやGoldBaseと呼ばれるものが登場していたんですね。
今回のre:Inventで発表されたAWS Config RulesやAWS Inspectorは、五月雨に出されたものではなく、セキュリティやコンプライアンスを高めるための一連の戦略の中に位置づけられているということが、よく理解できるセッションだったと思います。
Service Catalog関連のデモは、デモといいつつ動きがあるわけではなく概念の説明に終始していて、自分には正直分かりづらかったです。Service Catalogは東京リージョンにはまだ来ていませんが、ガバナンスを重視したい場合には外せないサービスのようです。今後キャッチアップしていきたいと思います。
それでは、また。
14
