AWS(5)セキュリティのベストプラクティス

概要

偶発的もしくは意図的な盗難漏洩不整合削除からミッションクリティカルな情報を保護するために、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ではIPSecSSL/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の使用
  • レート制限
  • ハーフオープンセッションの制限

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

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

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

AWS Identity and Access Management(1)IAMの概要

AWS Identity and Access Management (IAM)とは

AWS IAMは、AWSをセキュアに使用するための認証認可の仕組み。UserやGroupを作成してパーミッションを付与することができる。AccessKey, SecretKeyの取り扱いは注意が必要で定期的な更新が望ましい。また、Rootアカウント(アカウントを作成したときのID)はIAMの設定するポリシーが適用されない強力なアカウントになるので極力使用しない。

IAMで作成したユーザでマネージメントコンソールにログインすることが可能で、ログインURLはIAM Dashboardより確認編集することが可能である。

安全なアカウント管理のために

安全にアカウントを管理するためには以下の手法を講じることが望ましい。

  • ルートアカウントのアクセスキーを消去する
  • ルートアカウントをMFA認証にする
  • AWSが定期着したポリシーを利用する
  • ユーザにグループを割り当て、グループごとにポリシーを定義する
  • 最小限の権限のみを与える
  • EC2で動作するアプリケーションへは、アクセスキーではなくロールで権限を与える

セキュリティ監査

セキュリティ監査を実施することで高いセキュリティレベルを維持することができる。セキュリティ監査は、定期的もしくはユーザの増減があった際や、サービスの開始/停止時、不正アクセスが疑われる際などに推測を交えずに徹底的に行うと良い。

管理ポリシー

AWSアクセスへの管理権限をJSON形式で指定することが可能である。条件(Condition)は、項目を連ねた場合はAND、項目内で条件を連ねた場合はORとして扱われる。全てのアクセスはデフォルトで拒否、Allowが指定されれば許可、Denyが指定されれば明示的な拒否として扱われる。

分類 項目例 内容
Effect Allow or Deny 許可設定であればAllow, 拒否設定であればDeny
Action s3:createBucket 操作の指定、ワイルドカードも使用可能
Resource arn:aws:s3:::mybucket service:region:account:resouceの順で記述する
Condition “IPAddress”: {“AWS:SourceIP”: “192.168.0.1”} 条件を指定する

IAMロール

AWSサービスに対してAWSアクセスの管理権限を付与する仕組み。UserやGroupには紐付かない。例えばEC2からDynamoDBやS3にアクセスする場合は、EC2上にCredentialを置くのではなくインスタンス作成時に適切なIAMロールを紐付ける。EC2へのIAMロールの紐付けは、インスタンス作成時のみ可能であることに注意が必要である。

AWSCredentialsProvider

AWSの各サービスにアクセスするプログラムをEC2上で動作させる場合に、認証情報をCredentialsから取得するのか、IAMロールから取得するのか選択することができる。Credentialsから取得する場合はProfileCredentialsProviderを、IAMロールから取得する場合はInstanceProfileCredentialsProviderクラスを使用する。

// Credentialsから取得する場合
AWSCredentialsProvider credentialsProvider = new ProfileCredentialsProvider();

// IAMロールから取得する場合
//
// 引数(refreshCredentialsAsync)をtrueにすると認証情報を非同期に更新する新しいスレッドが生成される
// falseにすると認証情報の更新は、インスタンスメタサービスに合わせられる
AWSCredentialsProvider credentialsProvider = new InstanceProfileCredentialsProvider(true);

// 認証情報の取得
credentialsProvider.getCredentials();

STS(AWS Security Token Service)

AWSには、STS(AWS Security Token Service) と呼ばれる一時的に認証情報を付与するサービスが存在し、動的にIAMユーザを作成することができる。IAM Role for EC2はこの仕組みを利用している。有効期限は数分から数時間に設定可能である。