cloudpackエバンジェリストの吉田真吾（@yoshidashingo）です。

昨日、DevLOVE現場甲子園2014東日本大会に参加して現場目線でのAWSセキュリティあるある的な話をして来ましたが、AWSのセキュリティ全般について知りたい場合にどこらへんを読めばいいか聞かれたので、こちらで紹介しておきたいと思います。

AWSセキュリティセンター

AWSのセキュリティが気になる人はまずここを見ましょう。

全部読み進める、あるいは興味深いトピックから読み進めるということでよいと思いますが、私が注目する基本的な資料はホワイトペーパーとして提供されている「AWSセキュリティ概要（日本語）」「AWSセキュリティのベストプラクティス」「セキュリティ監査チェックリスト」あたりです。これをそれぞれを読み進めて行きながら、各サービスの用語や仕様で分からない部分があれば、該当の記事＆チュートリアル／セキュリティサービスのドキュメントを参照するとよいと思います。

[この記事で紹介するドキュメント]

  1. AWS セキュリティ概要（日本語）
  2. AWSセキュリティのベストプラクティス
  3. セキュリティ監査チェックリスト

1. AWSセキュリティ概要

このドキュメントでは「AWSがどのようにセキュリティを高めているか、AWS側の取組み」と「AWSユーザーが使うセキュリティ関連の機能をどう作っているか」概要が記載されています。この文章は、普段AWSの中身を見られない我々が、AWSが普段行っているさまざまな取組みを知ることができる大変興味深い資料なので読んでおいたほうがよいでしょう。

いくつか興味深い部分を挙げると、(サービスの)モニタリングについて書かれている章では、AWS内のシステムをモニタリングして早期警戒閾値を超えると、運用管理担当者のポケベルを鳴らし、特に協力体制が必要な場合においては「通話リーダー」という人が問題処理にかかる会議システムの支援を行うそうです。また、事後分析会議を行い、根本原因への予防措置の実施について、週次の運用会議で状況確認がされるそうです。

ストレージデバイスの廃棄の章では、ストレージデバイスが製品寿命に達した場合に、DoD 5220.22-M または NIST 800-88 に記載されている技術を用いてサニタイズを行ってから廃棄されるということが書かれています。

面白いですね、中ではこういうことをやってるんですね。

ただし、現在参照できるドキュメントは2011年5月版と結構古くて、ハイパーバイザーが準仮想化の話のみだったり、最新のアカウントで発行できないX.509証明書の話があったり、EBSがユーザーによる暗号化のみだったり、S3のアクセス制限に利用するのがバケットACLのみだったり、CloudTrailについて記載されていなかったりするので、そこらへんは差し引いて読み進める必要がありそうです。

早くアップデートしてもらえると嬉しいですね。

2. AWSセキュリティのベストプラクティス

上記AWSセキュリティセンター内のリソースに「AWS セキュリティのベストプラクティス」というホワイトペーパーがあります。このドキュメントでは「どのようにAWSを使うとセキュアに扱えるか」という内容が書かれています。

英語のドキュメントですが、目次としては以下のように書かれています。

  • AWSの共有責任モデルを知る
  • AWSでの資産の定義と分類
  • AWS上の資産を守るためにISMSを設計する
  • AWSアカウント、IAMユーザー、IAMグループ、IAMロールを管理する
  • Amazon EC2へのOSレベルのアクセスを管理する
  • データを保護する
  • OSやアプリケーションを保護する
  • インフラを保護する
  • セキュリティ監視、アラート、監査証跡、インシデント対応の管理

動画もあります

以下、どういうことが書かれているか目次別に概要を紹介したいと思います。

AWSの共有責任モデルを知る

ISMS（情報セキュリティマネジメントシステム）において、組織はコンピューターのセキュリティ対策だけでなく、組織としてどのようなポリシーで情報セキュリティの管理に取り組むか、具体的な計画、実施、振り返り、対策といったPDCAサイクルの構築し、運用していくように設計する必要があります。そのために「取り組むべきスコープの定義」を行う必要がありますが、AWSを利用する場合にどこまでがAWSの責任範囲で、どこからがユーザー企業の責任範囲なのかというのを明確にする必要があります。

そういったスコープを明確化するために「共有責任モデル」が定義されています。

AWSの40近いサービスは、大きく3種類のサービス種別に分けられており、その種別に応じて責任範囲が異なっていることをまず覚えておきましょう。

  • Infrastructure services（インフラ・サービス）：EC2、EBS、Auto Scaling、VPCなど
  • Container services（コンテナ・サービス）：RDS、EMR、Elastic Beanstalkなど
  • Abstracted services（抽象化されたサービス）：S3、Glacier、DynamoDB、SQS、SESなど
(1) Infrastructure servicesにおける共有責任モデル
  • AWS管理
    • ファシリティ
    • ハードウェアの物理セキュリティ
    • ネットワークインフラ
    • 仮想化基盤
  • EC2を例にした場合のカスタマー責任範囲
    • AMI
    • OS
    • アプリケーション
    • 送受信されるデータ
    • 保存データ
    • データストア
    • 認証情報
    • ポリシーや設定

ここではAWSのグローバルなインフラや、仮想サーバー基盤、ネットワークといった部分はAWSの管理範囲ですが、データや通信の暗号化、OSやファイアウォールの設定、顧客のデータの管理などはユーザーの責任範囲になっています。

(2) Container servicesにおける共有責任モデル

Container servicesにおける共有責任モデルでは、Infrastructure servicesにおけるAWSの管理範囲に加えて、OSやネットワーク設定、アプリケーション管理の領域までがAWSの管理範囲に含まれます。ファイアウォール設定やデータや通信の暗号化、、顧客のデータの管理などはユーザーの責任範囲になっています。

(3) Abstracted servicesにおける共有責任モデル

Abstracted servicesにおける共有責任モデルでは、Container servicesにおけるAWSの管理範囲に加えて、通信やサーバーサイド暗号化の機能的な責任担保はAWSの管理範囲に含まれます。クライアントサイド暗号化や、顧客のデータの管理などはユーザーの責任範囲になっています。

AWSでの資産の定義と分類

セキュアな情報システムを設計するうえでは「守るべきものは何か」を定義することが大前提になります。そういう意味で、AWS上に配置されるものをまず定義し、分類する作業がこの章になります。
資産は大きく分けて2つに分類されます。

  • ビジネスの情報やプロセス、活動といった基本要素
  • 基本要素を支えるハードウェア、ソフトウェア、人員、拠点、パートナー組織といったコンポーネント

AWS上の資産を守るためにISMSを設計する

資産、分類、コストが決定したら、AWS上でのISMAの実装、運用、監視、振り返り、メンテナンス、改善といった活動のための標準規約を作成します。セキュリティ要件は以下のような要因により、組織ごとに違うものになります。

  • ビジネスのニーズや目的
  • 採用するプロセス
  • 組織の規模や構造

AWSアカウント、IAMユーザー、IAMグループ、IAMロールを管理する

ユーザーごとに必要なアクセス権限に最小化する必要があります。日々の運用にAWSのrootアカウントを利用するのではなく、個別にIAMユーザーを作成し、必要な権限だけ付与する必要があります。なお、権限の付与は、IAMユーザー個別に設定も可能ですし、IAMグループに権限を設定し、グループ内のIAMユーザーはそれを継承して使うということが可能です。
また、IAM RoleというのがEC2に付与することが可能で、これはEC2のインスタンスメタデータでクレデンシャルを管理することで、EC2内からAWSリソースにAPIアクセスする場合にOS内でクレデンシャルを管理せずに、管理者側で設定が可能な便利な機能です。

Amazon EC2へのOSレベルのアクセスを管理する

EC2インスタンスを作成するときには公開鍵暗号方式のキーペアを作成したり、自身で生成した鍵を登録することができ、OSへのアクセスの前に認証を行う必要があります。

データを保護する

リソース単位にどんなユーザー（IAMユーザー、グループ、ロール）がアクセス可能か設定したり、保存データをどう保護するかについて書かれています。
各サービスごとの詳細なデータ保護方法が記載されています。

OSやアプリケーションを保護する

EC2上のOSやアプリのセキュリティを担保する責任はユーザーがわにあります。この章では、自身の要件にあったカスタムAMIを作って公開する際に気をつけることや、セキュリティパッチの推奨、マルウェアからの防衛方法や、AWSからのAbuse連絡への対応などのアプリケーションを保護する方法が示されています。

インフラを保護する

VPCの使い方、VPCでできること、ネットワークセキュリティの強化方法、攻撃の緩和方法などが記載されています。

セキュリティ監視、アラート、監査証跡、インシデント対応の管理

ユーザーが管理すべきOSより上のレイヤーにおいてもセキュリティの監視は必要です。OSより上の話なので、既存のプロセス、ツール、方法論が使えます。どのパラメータでどのように、どこを閾値にしてどうエスカレーションし、どこに保持しておくかといったことを考慮する必要がありますし、たとえば監視方法がログであれば、どう収集してどう分析し、どう格納するかなどを考える必要があります。クリティカルなトランザクションを運用しているところなども変更管理ログを取得したほうがよいですし、ログ自体をどう保管するかということも考慮する必要があります。

3. AWSの使用に関するセキュリティ監査チェックリスト

最後に、セキュリティ監査チェックリストを読んでみましょう。取組みの結果、抜けがないか確認することができると思います。

このドキュメントは、開発者やアーキテクトが 運用チェックリスト を用いて構築したシステムをチェックするように、社内コンプライアンスチームや監査担当者が社内レビューや外部監査を行う際のアシストとして利用することを目的に提供しているそうです。

これからAWSを始める人は一読すべき「AWS運用チェックリスト」を読んでみた ｜ Developers.IO

目次としては以下のようになっており「AWSセキュリティのベストプラクティス」にも対応した内容になっているようです。

  • 監査前の手順
  • ガバナンス
  • 資産の設定と管理
  • 論理アクセス制御
  • データの暗号化
  • ネットワークの設定と管理
  • セキュリティのロギングとモニタリング
  • セキュリティインシデントの対応
  • 障害復旧

以下、どういうことが書かれているか目次別に概要を一部引用して紹介したいと思います。

監査前の手順

監査の実施前に、監査計画と範囲を確認します。

  • 組織内のAWSの使用を理解する。
  • AWS監査目標を定義する。
  • レビュー対象のAWSの境界を定義する。
  • リスクを特定する。
  • リスクを確認する。
  • リスク関連文書を見直す。
  • AWSの使用をリスク評価に組み込む。

ガバナンス

AWSを利用したシステムやデータの種類、それらに適用されるポリシーや手順、計画を評価し、リスクを評価し、クラウドの利用が監査プログラムに含まれているかチェックします。

  • 資産を識別する。
  • ポリシーを評価する。
  • リスクを評価する。
  • 監査計画を変更する。

資産の設定と管理

OSやアプリケーションのセキュリティ保守はAWSユーザー側の責任範囲であるため、これらが組織のポリシー、手順、基準にしたがって設計、設定、パッチ処理運用などされているかチェックします。

  • 資産インベントリのリストを取得する。
  • パッチ処理を評価する。
  • 設定管理を評価する。
  • 権限アクセスを評価する。

論理アクセス制御

リソースへのユーザーのアクセス権限、実行可能な操作の種類などの許可状態が、組織のポリシー、手順、基準にしたがって管理されていることをチェックします。

  • AWSアカウント管理を評価する。
  • Multi-Factor Authentication（MFA）を評価する。
  • Identify and Access Management（IAM）ユーザーアカウントを確認する。
  • グループの許可を確認する。
  • 組織のシステムユーザーアカウントを確認する。
  • アプリケーションとシステムプロセスのアクセス認証情報を評価する。
  • IAM ロールを評価する。
  • アクセス制御テストを実施する。
  • AWS リソースに対する許可管理を文書化する。

データの暗号化

データの暗号化についてはAWS側で提供しているオプションもあるし、クライアント側で暗号化することもできます。データがどこにあるか理解し、伝送路上や保存場所における保護の方法をチェックします。

  • データ資産と要件を特定する。
  • 保管時のデータの暗号化を確認する。
  • 転送時のデータの暗号化を確認する。

ネットワークの設定と管理

AWSではネットワークコンポーネントが全て仮想化されており、ユーザーはこれを使ってネットワークの設定、管理を行います。組織のセキュリティ要件に応じてリソースの分割やトラフィックの制限などが行われていることをチェックします。

  • EC2 インスタンスへのトラフィックを確認する。
  • VPC ネットワークへのトラフィックを確認する。
  • 追加のネットワーク制御を確認する。

セキュリティのロギングとモニタリング

セキュリティ計画にAWS上でのアクティビティの監視が含まれていることを確認し、記録される監査ログが適切に設定されて保護されることをチェックします。

  • ロギング要件を確認する。
  • ユーザーアクセスロギングを確認する。
  • 変更管理ロギングを確認する。
  • ログの保護を確認する。
  • モニタリングメカニズムや手順を確認する。

セキュリティインシデントの対応

セキュリティイベントは、資産がオンプレにあろうがAWSのどこかにあろうがモニタリングできなければなりません。また、AWSが管理する範囲とユーザーが管理する責任範囲を理解し対応プロセスを調整する必要があります。

  • 現在のインシデント管理プロセスを評価する。
  • インシデント管理計画を確認する。
  • インシデント管理計画通信を評価する。

障害復旧

AWSが提供しているコンポーネントを適切に利用して、要件にあった可用性や復旧時間が実現できるよう設定されているかチェックします。

現在

  • の状態を理解する。
  • インシデント管理計画を確認する。
  • インシデント管理計画通信を評価する。
  • AWS 機能の使用を評価する。
  • DR テストを確認する。

また、最後にAWS Trusted Adviserが紹介されており、セキュリティ関連の推奨事項のチェックに活用できることが分かります。

まとめ

ということで、ここではAWSのセキュリティベストプラクティスから、そのチェックリストを紹介してみましたが、AWSセキュリティセンターにはこれ以外にもたくさんの資料があるので、AWSのセキュリティがどうなのか気になったら、自分で調べられるようにしておきましょう。

DevLOVEで話したネタ

で、最後に昨日DevLOVEで話してきたネタです。20分だったので、特にプリセールスやってきて現場で感じるところをあるある話でまとめてみました。

Security BEFORE the Cloud // Speaker Deck

元記事はこちらです。
「AWSのセキュリティが気になるなら読んでおくべきAWSセキュリティのベストプラクティス」