概要

偶発的もしくは意図的な盗難、漏洩、不整合、削除からミッションクリティカルな情報を保護するために、Information Security Management System (ISMS)を作成するためのガイドライン。

責任共有モデル

AWSでは、AWS が安全なインフラストラクチャとサービスを提供する一方で、ユーザは安全なオペレーティングシステム、プラットフォーム、データを用意する責任を持つ、責任分担モデルを採用している。例えばEC2の場合は、設備やハードウェアの物理的セキュリティ、ネットワークインフラ、仮装化インフラはAWSが管理する一方で、AMI、OS、アプリケーション、データ、認証情報等は、ユーザ自らが管理しなければならない。

Trusted Advisorの利用

Trusted Advisorを利用してサービスの状況を確認し、セキュリティの設定ミスやシステムパフォーマンスの向上に関する提案、使用率の低いリソースの確認などを行うことができる。例えば、管理ポートへのアクセスが限定的なものであるかや、IAMが設定されているか、MFAが有効化されているかなどが確認できる。

アセット

ISMSを設計する前に情報アセットを特定し、これらを保護するために必要なソリューションを技術面とコスト面から検討する必要がある。アセットは、業務の情報やプロセスなどを含む本質的な要素と、ハードウェアやソフトウェア、人員などを含む本質的な要素をサポートする要素の2つに大別される。

アセットの例

アセット名	アセットの所有者	アセットカテゴリ	依存関係	コスト
顧客向けアプリケーション	eコマースチーム	必須	EC2, RDS…
AWS Direct Connect	最高情報責任者(CIO)	ネットワーク	ネットワーク運用, Direct Connect

これらのアセットを保護するために、情報セキュリティマネージメントシステム(ISMS) の実装、運用、モニタリング、確認、保守、改良に関する基準を定める必要がある。このとき、ビジネスニーズや目標、プロセス、組織の規模や構造などを考慮して基準を定める。ISMSの設計には、ISO27001 などの標準的なフレームワークを参考にすると良い。

段階	内容	詳細
1	スコープと境界の定義	スコープに含めるリージョン、AZ、リソース等を定義する。除外するリソースがある場合はその除外理由を明記する。
2	ISMSポリシーの定義	情報セキュリティの方向性と指針、法律や契約の要件、リスクの評価方法や承認方法
3	リスクの評価方法の選択	ビジネスニーズ、セキュリティ要件、IT機能と要件、法規制
4	リスクの特定	アセットとアセットに対する脅威を記した登録簿の作成、脆弱性とその結果
5	リスクの分析と評価
6	リスクへの対処	リスクを受け入れる、回避する、リスクレベルの査定
7	セキュリティコントロールフレームワークの選択	ISO 27002、NIST SP 800など
8	マネジメントによる承認の取得	残留リスクの報告と承認
9	適用宣言書の作成	選択したフレームワーク、導入済/予定のフレームワーク、除外したフレームワークとその理由

AWSアカウント

AWSアカウントは非常に強力な権限を有するので日常的な使用はせず、極力IAMユーザを使用する。またIAMユーザは、（特定のグループに所属するIAMユーザが1名だけであった場合でも）IAMグループを利用し、またきめ細やかに権限を付与し、タスクに必要な最小限のアクセス権限を付与する。また、AWSのアカウントは、セキュリティの観点から単一アカウントで処理する、開発ステージごとにアカウントを分割する、などビジネスやガバナンスの要件を満たすように設計することが必要である。AWSアカウントを複数有する場合は、一括請求アカウントを利用することで、管理の複雑さを低減し、スケールメリットを享受することができる。

アクセスキーを利用する場合は、定期的に更新を行う。また、IAMユーザの認証にはMFAの併用が望ましい。複数のAWSアカウントを横断的に利用する場合には、クロスアカウントアクセスの利用も検討する。社内に既にディレクトリサービスを有する場合には、IDフェデレーションの利用も可能である。EC2から他のAWSリソースを利用する場合はIAMロールを使用する。

データの保護

リソースへのアクセス保護

リソースへのアクセスは、各リソースを作成したユーザが他のユーザに対してアクセスを許可するリソースポリシーと、IAMユーザやIAMグループを使用して付与される機能ポリシーのいずれかを単独でもしくは組み合わせて使用する。

保管時のデータ保護

以下の課題を考慮して、データの保護を行う手法を検討する

• 偶発的な情報開示や漏洩
• データの不整合や不正な書き換え
• 過失による削除
• システム障害や災害に備えたシステムの可用性

S3におけるデータ保護

• アクセス権限の付与
• バージョニング
• レプリケーション
• バックアップ
• サーバサイド暗号化
• クライアントサイド暗号化

EBSにおけるデータ保護

• レプリケーション
• バックアップ（スナップショット）
• 暗号化

RDSにおけるデータ保護

• 暗号化関数の使用
• アプリケーションレベルの暗号化

Glacierにおけるデータ保護

• サーバサイド暗号化
• クライアントサイド暗号化

DynamoDBにおけるデータ保護

• Base64エンコード

EMRにおけるデータ保護

• S3のサーバサイド暗号化
• S3のクライアントサイド暗号化
• アプリケーションレベルの暗号化

伝送中のデータ保護

以下の課題を考慮して、データの保護を行う手法を検討する

• 偶発的な情報開示や漏洩
• データの不整合や不正な書き換え
• なりすましや中間者攻撃

伝送中のデータを保護するために、AWSではIPSecやSSL/TSLをサポートしている。また、Remote Desktop Protocol(RDP)の使用やSSHの使用も有効である。

S3へ伝送中のデータ保護

• SSL/TSLを用いた通信

RDSへ伝送中のデータ保護

• SSL/TSLを用いた通信
• X.509証明書

DynamoDBへ伝送中のデータ保護

• HTTPSの利用

OSとアプリケーションのセキュリティ保護

OSとアプリケーションのセキュリティを保護するためには以下が奨励される。

• ルートアクセスキーとシークレットキーの無効化
• IPアドレスを限定したインスタンスへのアクセス
• pemファイルのパスワード保護
• ユーザの管理
• 認証情報の更新
• IAMユーザのアクセス権を定期的に管理

AMIを公開する場合は、認証情報をOS上から消去しておくなど、セキュリティ面には十分注意する。

万が一、OS等への侵入が確認された場合に、根本的な原因追求を行うためにフォレンジックを行う。

ブートストラッピング

PuppetやChefなどを利用してセキュリティプログラムの更新や、パッチの適用、ステージに合わせた環境設定の実行、リモートモニタリング等を実施する。

マルウェアからの保護

信頼できないAMIやコードは実行しない。また、信頼できないソフトウェアリポジトリも使用しない。ユーザに付与する権限は必要最小限とし、ウイルスおよびスパム対策ソリューションを必ず利用する。

その他の対策

• ベンダー指定のデフォルト値を削除する
• 不要なユーザを無効化する
• EC2に複数の機能を持たせない
• 必要なサービスやデーモンのみ有効化する
• 不要な機能やWebサーバは無効化する

インフラの保護

インフラを保護するためには以下を行う。

VPCの利用

VPCを利用することで、AWSのパブリッククラウド内にプライベートクラウドを作成できる。他のAWSユーザからリソースを隔離できるということだけでなく、インターネットから隔離することもできる。また、IPSecやDirect Connectを利用することでオンプレミス拠点とAWS間をセキュアに接続することも可能である。

セキュリティグループやNACLを使用することで、セキュリティゾーニングを実現することができる。この際に、セキュリティゾーン間の通信を制御するか、ゾーン間の通信をモニタリングするか、ゾーンごとにアクセス権限を付与するか、などを検討する必要がある。

セキュリティのテスト

セキュリティコントロールとポリシーの有効性を定期的にレビューする。新しい脅威や脆弱性に対処するためには、外部脆弱性評価や外部侵入テスト、アプリケーションとプラットフォームの内部グレー/ホワイトボックスレビューを行う。なお、侵入テストを行う場合には、AWSにリクエストが必要な場合がある。

メトリクスの管理と向上

有効性の測定を行う上では、メトリクスの利用が有効的である。

• 手順のモニタリング
  • 処理結果からエラーを迅速に検出する
  • セキュリティ侵害やインシデントに迅速に対応する
  • セキュリティアクティビティが想定通りに実行されているか判断する
  • セキュリティイベントを検知してインシデントを防止する
  • 対処が効果的であったか判断する
• ISMSの有効性のレビュー
  • セキュリティ監査、インシデント、有効性測定
  • 関係者からの提案およびフィードバック
  • ポリシーが目的に合っているかの確認
• 有効性の測定
  • セキュリティ要件を満たしているかどうか
• 定期的なリスク評価レビュー
  • 残留リスクの許容可能なリスクのレビュー
  • 法改定など外部イベントに適しているか
• 内部監査
• 定期的な管理レビュー
  • スコープが適切か
• セキュリティ計画の更新

DoSおよびDDoS攻撃の緩和と保護

DoSおよびDDoSについて懸念がある場合には、AWSのサポートの契約が望ましい。サポートに契約することで、AWSがDoSおよびDDoS攻撃の事前および事後にサポートを提供できる。AWSは、トラフィックが攻撃によるものかは判断できないために、アクティブに対処することはしない。これらの攻撃に対処するためには、以下の手法を検討する。

• セキュリティグループやNACLの使用
• WAFの使用
• レート制限
• ハーフオープンセッションの制限

モニタリングと監査、インシデント対応

ログファイルを蓄積することで、適切なモニタリングとて監査、インシデント対応を行うことができる。

エリア	考慮事項
ログ収集	収集方法に注意する
ログ転送	ログファイルを安全、確実、タイムリーに転送する
ログストレージ	一元管理し分析を行う
ログ分類	分析に適した形式
ログ分析	ログファイル内のイベントを相互に関連付ける
ログの保護	改ざん等を防ぐ