この記事は公開されてから1年以上経過しています。情報が古い可能性がありますので、ご注意ください。
「AWS Well-Architected Framework」
先日、AWSより「AWS Well-Architected Framework」というドキュメントが公開されました。この文書は、みなさんがより良いクラウドベース設計を評価改善し、設計によるビジネスへの影響についてより良い理解をするためのものです。AWSで良い設計をしているかを定義する柱として、4つの分野におけるベストプラクティスとガイドを定義し、一般的な設計指針について取り組みます。
4つの柱
「AWS Well-Architected Framework」で示されている4つの柱は以下のとおりです。
- セキュリティ（Security） リスクアセスメントとマイグレーション戦略を通じたビジネス価値の提供による、情報・システム・資産を保護する能力について
- 信頼性（Reliability） システムの能力を動的に需要を満たすためにコンピューティング資源を獲得し、インフラやサービスの障害からの回復、およびそのような設定ミスや一時的なネットワークの問題などの混乱を軽減する能力について
- パフォーマンス効率（Performance Efficiency） システム要件を満たすことと、需要の変化や技術の進化を前提し、その効率を維持するために効率的にコンピューティングリソースを使用する能力について
- コスト最適化（Cost Optimization） 最適ではないリソースや不要なコストを回避または取り除く能力について
質問＆回答とベストプラクティス（セキュリティ編）
SEC 1：どのように保存データを暗号化して保護しますか？
クライアント側であれば、SDK-supported, OS-supported, Windows Bitlocker, dm-crypt, Trend Micro SafeNet等で、サーバー側であれば、Amazon S3等です。Server-Side Encryption (SSE)やAmazon Elastic Block Store 暗号化ボリュームを使うことができます。
☆ベストプラクティス
- Amazon S3 SSE、Amazon EBS 暗号化ボリューム、Amazon RDS TDE（透過的データ暗号化）等を用いる
- クライアント側技術により保存データを暗号化する
- AWS MarketplaceやAPNパートナーのソリューションを利用する
SEC 2：どのように転送データを暗号化して保護しますか？
ベストプラクティスは暗号化することです。AWSは、各サービスのAPIエンドポイント利用時に暗号化しています。加えて、利用者はAmazon EC2内で様々なテクニックを用いることができます。
☆ベストプラクティス
- AWSの各API利用時に適切にSSLを有効にする
- コミュニケーションのためにSSLまたは同等の技術を用いる。
- VPNベースのソリューション
- プライベート接続（例：AWS Direct Connect）
- AWS Marketplaceソリューションの利用
SEC 3：どのようにAWS rootアカウントの資格情報へのアクセスと使用を保護しますか？
AWS rootアカウントは、OSの管理者やルート権限者と同じように非常に慎重に扱う必要があります。現在のベストプラクティスは、AWS Identity and Access Management (IAM)ユーザを発行して、管理者グループに所属させ、IAMユーザを利用させることでアカウントを管理することです。AWS rootアカウントはAPIキーを使用するべきではなく、強度のパスワードを持ち、ハードウェアMFAを使用し、プログラミングからのAPI利用を制限して、AWS管理コンソールからの利用のみにするべきです。いくつかのリセラーやリージョンはAWS rootアカウントの配布やサポートを行なっていませんので注意してください。
☆ベストプラクティス
- AWS rootアカウントの資格情報は、最小に限定された利用に留める
- AWS rootアカウントの使用時は、MFAデバイスを用いる。
- AWS Marketplaceソリューションの利用
SEC 4：AWS管理コンソールとAPIへのアクセスを管理するために、どのようにロールや責務を定義しますか？
現在のベストプラクティスは、ユーザグループの作成によって、システム利用者のロールと責務を分離することです。ユーザグループには、いくつかの異なる技術を用いることができます。Identity and Access Management (IAM)グループ、クロスアカウント接続のためのIAMロール、Webアイデンティティ、SAML（Security Assertion Markup Language）統合（例：Active Directoryロール）、サードパーティのソリューション（例：Okta、Ping Identity、その他）による、SAMLやAWS Security Token Service (STS)を用いた統合、強度の共通パスワードなどです。
☆ベストプラクティス
- IAMユーザとグループ
- SAML統合
- Web IDフェデレーション
- AWS STS
- クロスアカウント接続のためのIAMロール
- AWS Marketplaceのソリューション（例：Okta、Ping Identity、その他）または、APNパートナーのソリューション
- 従業員のライフサイクルポリシーの定義と強制
- ユーザ、グループ、ロールを明確に定義して、業務要件に必要な最低限の権限を付与すること
SEC 5：どのようにAWSリソースへの自動アクセスを制限しますか？（例えば、アプリケーション、スクリプト、サードパーティ製のツールやサービス）
体系的なアクセスは、例えば入社時にあるグループに所属されるのと同じように定義されるべきです。Amazon EC2インスタンスを例にとると、IAMロール for EC2があります。現在のベストプラクティスは、EC2用にIAMロールを利用します。AWS SDKやCLIは、IAMロールを通じたEC2資格情報へのアクセスについて、ビルトインのサポートを行なっています。そのため、資格情報についてスクリプトにハードコーディングすべきではありません。
☆ベストプラクティス
- IAMロール for EC2
- IAMユーザの資格情報を利用する。ただし、アプリケーションやスクリプト内にハードコードしないこと。
- SAML統合
- AWS STS
- EC2インスタンスのためのOS指定のコントロール
- AWS Marketplaceソリューションの利用
SEC 6：どのようにキーや資格情報を管理しますか？
キーと資格情報は保護されるべき秘密情報で、ローテーションポリシーを定義して使用する必要があります。ベストプラクティスは、アプリケーションや管理スクリプトにハードコードしないことですが、これはしばしば起こります。
☆ベストプラクティス
- 使用しているキーや資格情報にローテーションポリシーを充てる
- AWS CloudHSMの利用
- AWS管理のキー（Amazon S3 SSE, Amazon EBS暗号化ボリューム等）と一緒にAWSサーバサイドのテクニックを使う
- AWS Marketplaceソリューション（例：SafeNet、TrendMicro）
SEC 7：どのようにして、ネットワークとホストレベルの境界を運用しますか？
オンプレミスのデータセンターでは、DMZアプローチによって、信頼ゾーンと非信頼ゾーンをファイアウォールを使って分けていました。AWSでは、ステートフルとステートレス両方のファイアウォールを利用します。ステートフルファイアウォールはセキュリティグループと呼ばれ、ステートレスファイアウォールはネットワークACLと呼ばれ、Amazon VPC内のサブネットを保護します。現在のベストプラクティスは、VPC内でシステムを稼働させることです。そして、セキュリティグループでロールベース（Web層、App層等）のセキュリティを定義することです。そして、ロケーションベースのセキュリティをネットワークACL（AZ毎のサブネットにおけるELB層、AZ毎の他のサブネット内のWeb層等）によって定義します。
☆ベストプラクティス
- 最小権限のロールベースアクセスの運用を行うセキュリティグループ
- VPC内でシステムを稼働
- プライベートな方法を用いた信頼されたVPCへのアクセス（例：VPN、IPsecトンネル、AWS Direct Connect、AWS Marketplaceソリューション等）
- 適切なサブネットとネットワークACL
- 最小権限のホストベースのファイアウォールの利用
- サービス指定のアクセスコントロールの利用（例：バケットポリシー等）
- VPCへのプライベート接続（例：VPN、AWS Direct Connect、VPC peering等）
- インタンスの管理のために踏み台サーバの利用
- 定期的なセキュリティテストの実施
- AWS Trusted Advisorチェックによる定期的なレビュー
SEC 8：どのようにAWSサービスレベルの保護を運用しますか？
他のベストプラクティスは、リソースへのアクセスを制御することです。IAMはリソースレベル制御（例：暗号化、日時、ソースIP等）を定義でき、サービスは追加の手法（S3バケットポリシー等）を用いることができます。加えて、利用者はEC2インスタンス内で指定した手法と合わせて利用することができます。
☆ベストプラクティス
-
最低限の権限を使用して資格情報を設定する - 責務の分離
- 権限の定期的な監査
- MFA認証や暗号化など機密情報のAPI呼び出しなどがリソース要件として定義されている
- サービス固有の要件を定義して使用
- AWS Marketplaceソリューションの利用
SEC 9：どのようにあなたのAmazon EC2インスタンス上でオペレーティングシステムの完全性を保護しますか？
他に伝統的なコントロール方法は、OSの完全性を保護することです。これは簡単に実現できます。従来のホストベースの技術（例：OSSEC、Tripwireの、トレンドマイクロのDeep Security等）をEC2内で用います。
☆ベストプラクティス
-
ファイルの整合性チェック
- ホストベースのIDS（侵入検知コントロール）
- AWS Marketplaceソリューションの利用
-
初期状態でセキュリティ設定済みのカスタムAMIまたは構成管理ツールの使用（PuppetやChef）
SEC 10：どのようにAWSログをキャプチャして分析しますか？
ログをキャプチャすることは、セキュリティインシデントの全てを調査するために重要です。現在のベストプラクティスは、定期的にログ処理システム（例：Splunk、Papertrail等）に直接ソースから送ったり、後から発生するであろうビジネス要求のためにS3に保存することなどです。ログの一般的なソースは、AWS APIとユーザ関連のログ（CloudTrail等）、AWSサービス固有のログ（S3、CloudFront）、OS生成のログ、サードパーティアプリのログです。
☆ベストプラクティス
-
AWS CloudTrail
- ELBログ
- VPCフィルターログ
- S3バケットログ
- CloudWatchログ
- その他AWS提供のログ
- OSやサードパーティのアプリケーションログ
- AWS Marketplaceソリューションの利用
まとめ
普段何気なく設定しているセキュリティについて、体系的にまとまっていて、AWSへの理解を深めることができました。外部監査や認証を受ける際に役立つのではと思っています。クラウドだから特別というものではなく、一般的に考慮するべきセキュリティ項目について、AWSは最初からサービスや機能として用意されていることがこのプラットフォームの強みだと思います。
参考資料
Are You Well-Architected?
- Documentation & Blogs
- Whitepapers
- Videos
4
