2014.08.28xfacebookはてなブックマークpocket#アクセス制限#セキュリティcloudpackエバンジェリストの吉田真吾(@yoshidashingo)です。昨日、DevLOVE現場甲子園2014東日本大会に参加して現場目線でのAWSセキュリティあるある的な話をして来ましたが、AWSのセキュリティ全般について知りたい場合にどこらへんを読めばいいか聞かれたので、こちらで紹介しておきたいと思います。AWSセキュリティセンターAWSのセキュリティが気になる人はまずここを見ましょう。日本語)全部読み進める、あるいは興味深いトピックから読み進めるということでよいと思いますが、私が注目する基本的な資料はホワイトペーパーとして提供されている「AWSセキュリティ概要(日本語)」「AWSセキュリティのベストプラクティス」「セキュリティ監査チェックリスト」あたりです。これをそれぞれを読み進めて行きながら、各サービスの用語や仕様で分からない部分があれば、該当の記事&チュートリアル/セキュリティサービスのドキュメントを参照するとよいと思います。AWSセキュリティ概要このドキュメントでは「AWSがどのようにセキュリティを高めているか、AWS側の取組み」と「AWSユーザーが使うセキュリティ関連の機能をどう作っているか」概要が記載されています。この文章は、普段AWSの中身を見られない我々が、AWSが普段行っているさまざまな取組みを知ることができる大変興味深い資料なので読んでおいたほうがよいでしょう。セキュリティ概要(日本語)いくつか興味深い部分を挙げると、(サービスの)モニタリングについて書かれている章では、AWS内のシステムをモニタリングして早期警戒閾値を超えると、運用管理担当者のポケベルを鳴らし、特に協力体制が必要な場合においては「通話リーダー」という人が問題処理にかかる会議システムの支援を行うそうです。事後分析会議を行い、根本原因への予防措置の実施について、週次の運用会議で状況確認がされるそうです。記載されている技術を用いてサニタイズを行ってから廃棄されるということが書かれています。面白いですね、中ではこういうことをやってるんですね。現在参照できるドキュメントは2011年5月版と結構古くて、ハイパーバイザーが準仮想化の話のみだったり、最新のアカウントで発行できないX.509証明書の話があったり、EBSがユーザーによる暗号化のみだったり、S3のアクセス制限に利用するのがバケットACLのみだったり、CloudTrailについて記載されていなかったりするので、そこらへんは差し引いて読み進める必要がありそうです。早くアップデートしてもらえると嬉しいですね。セキュリティのベストプラクティス」というホワイトペーパーがあります。このドキュメントでは「どのようにAWSを使うとセキュアに扱えるか」という内容が書かれています。Practices英語のドキュメントですが、目次としては以下のように書かれています。YouTube以下、どういうことが書かれているか目次別に概要を紹介したいと思います。AWSの共有責任モデルを知るISMS(情報セキュリティマネジメントシステム)において、組織はコンピューターのセキュリティ対策だけでなく、組織としてどのようなポリシーで情報セキュリティの管理に取り組むか、具体的な計画、実施、振り返り、対策といったPDCAサイクルの構築し、運用していくように設計する必要があります。そのために「取り組むべきスコープの定義」を行う必要がありますが、AWSを利用する場合にどこまでがAWSの責任範囲で、どこからがユーザー企業の責任範囲なのかというのを明確にする必要があります。いったスコープを明確化するために「共有責任モデル」が定義されています。AWSの40近いサービスは、大きく3種類のサービス種別に分けられており、その種別に応じて責任範囲が異なっていることをまず覚えておきましょう。servicesにおける共有責任モデルAWS管理ファシリティハードウェアの物理セキュリティネットワークインフラ仮想化基盤EC2を例にした場合のカスタマー責任範囲AMIOSアプリケーション送受信されるデータ保存データデータストア認証情報ポリシーや設定ここではAWSのグローバルなインフラや、仮想サーバー基盤、ネットワークといった部分はAWSの管理範囲ですが、データや通信の暗号化、OSやファイアウォールの設定、顧客のデータの管理などはユーザーの責任範囲になっています。servicesにおけるAWSの管理範囲に加えて、OSやネットワーク設定、アプリケーション管理の領域までがAWSの管理範囲に含まれます。ファイアウォール設定やデータや通信の暗号化、、顧客のデータの管理などはユーザーの責任範囲になっています。servicesにおけるAWSの管理範囲に加えて、通信やサーバーサイド暗号化の機能的な責任担保はAWSの管理範囲に含まれます。クライアントサイド暗号化や、顧客のデータの管理などはユーザーの責任範囲になっています。AWSでの資産の定義と分類セキュアな情報システムを設計するうえでは「守るべきものは何か」を定義することが大前提になります。いう意味で、AWS上に配置されるものをまず定義し、分類する作業がこの章になります。資産は大きく分けて2つに分類されます。返り、メンテナンス、改善といった活動のための標準規約を作成します。セキュリティ要件は以下のような要因により、組織ごとに違うものになります。採用するプロセス組織の規模や構造AWSアカウント、IAMユーザー、IAMグループ、IAMロールを管理するユーザーごとに必要なアクセス権限に最小化する必要があります。日々の運用にAWSのrootアカウントを利用するのではなく、個別にIAMユーザーを作成し、必要な権限だけ付与する必要があります。権限の付与は、IAMユーザー個別に設定も可能ですし、IAMグループに権限を設定し、グループ内のIAMユーザーはそれを継承して使うということが可能です。RoleというのがEC2に付与することが可能で、これはEC2のインスタンスメタデータでクレデンシャルを管理することで、EC2内からAWSリソースにAPIアクセスする場合にOS内でクレデンシャルを管理せずに、管理者側で設定が可能な便利な機能です。EC2へのOSレベルのアクセスを管理するEC2インスタンスを作成するときには公開鍵暗号方式のキーペアを作成したり、自身で生成した鍵を登録することができ、OSへのアクセスの前に認証を行う必要があります。データを保護するリソース単位にどんなユーザー(IAMユーザー、グループ、ロール)がアクセス可能か設定したり、保存データをどう保護するかについて書かれています。各サービスごとの詳細なデータ保護方法が記載されています。OSやアプリケーションを保護するEC2上のOSやアプリのセキュリティを担保する責任はユーザーがわにあります。この章では、自身の要件にあったカスタムAMIを作って公開する際に気をつけることや、セキュリティパッチの推奨、マルウェアからの防衛方法や、AWSからのAbuse連絡への対応などのアプリケーションを保護する方法が示されています。インフラを保護するVPCの使い方、VPCでできること、ネットワークセキュリティの強化方法、攻撃の緩和方法などが記載されています。セキュリティ監視、アラート、監査証跡、インシデント対応の管理ユーザーが管理すべきOSより上のレイヤーにおいてもセキュリティの監視は必要です。OSより上の話なので、既存のプロセス、ツール、方法論が使えます。どのパラメータでどのように、どこを閾値にしてどうエスカレーションし、どこに保持しておくかといったことを考慮する必要がありますし、たとえば監視方法がログであれば、どう収集してどう分析し、どう格納するかなどを考える必要があります。クリティカルなトランザクションを運用しているところなども変更管理ログを取得したほうがよいですし、ログ自体をどう保管するかということも考慮する必要があります。AWSの使用に関するセキュリティ監査チェックリスト最後に、セキュリティ監査チェックリストを読んでみましょう。取組みの結果、抜けがないか確認することができると思います。用いて構築したシステムをチェックするように、社内コンプライアンスチームや監査担当者が社内レビューや外部監査を行う際のアシストとして利用することを目的に提供しているそうです。Developers.IO目次としては以下のようになっており「AWSセキュリティのベストプラクティス」にも対応した内容になっているようです。いうことが書かれているか目次別に概要を一部引用して紹介したいと思います。監査の実施前に、監査計画と範囲を確認します。組織内のAWSの使用を理解する。AWS監査目標を定義する。レビュー対象のAWSの境界を定義する。