「AWS Black Belt Online Seminar – Amazon Inspector」レポート
こんにちは、虎塚です。
2016年6月22日(水)のAWS Black Belt Online Seminarを受講したので、レポートします。
今回は、AWSの脆弱性診断サービスAmazon Inspectorの初級者向けセミナーで、講師はアマゾン ウェブ サービス ジャパンの桐山さんでした。
今回のセミナーでは、終盤で紹介されたAmazon Inspectorの使い時が素晴らしい内容でした。時間がない方はその部分をご覧ください。
セキュリティ診断について
セキュリティ診断の目的 : リスクの可視化
セキュリティ診断をおこなう目的の1つは、リスクの可視化です。
経済産業省のサイバーセキュリティ経営ガイドラインは、経営者がサイバーセキュリティをどう捉えるかをまとめたものです。サイバーセキュリティ経営ガイドラインには、3つの原則と10個の重要指針が示されています。
10個の項目を見てみましょう。特に1〜3番目の項目で、セキュリティリスクに対策をするように書かれています。
- サイバーセキュリティリスクの認識、組織全体での対応の策定
- サイバーセキュリティリスク管理体制の構築
- サイバーセキュリティリスクの把握と実現するセキュリティレベルを踏まえた目標と計画の策定
- サイバーセキュリティ対策フレームワーク構築 (PDCA) と対策の開示
- 系列企業や、サプライチェーンのビジネスパートナーを含めたサイバーセキュリティ対策の実施及び状況把握
- サイバーセキュリティ対策のための資源 (予算、人材等) 確保
- ITシステム管理の外部委託範囲の特定と当該委託先のサイバーセキュリティ確保
- 情報共有活動への参加を通じた攻撃情報の入手とその有効活用のための環境整備
- 緊急時の対応体制 (緊急連絡先や初動対応マニュアル、CSIRT) の整備、定期的かつ実践的な演習の実施
- 被害発覚後の通知先や開示が必要な情報の把握、経営者による説明のための準備
サイバーセキュリティに対策するためには、まずは社内にあるリスクを可視化する必要があります。そこでセキュリティ診断が重要になります。
セキュリティリスクの方程式
セキュリティリスクは、次の要因が存在することで発生します。
- 脅威 (Threats)
- 標的型攻撃、マルウェア、サイバー攻撃など（特に、外部からくる、自分の力でコントロールしにくいもの）
- 脆弱性 (Vulnerabilities)
- セキュリティホール、設定ミス、心理的要素（穴、隙などのポイント）
- 情報資産 (Assets)
- 機密情報、顧客や従業員の個人情報、知的財産
脆弱性が多いほど、そして情報資産の価値が大きいほど、リスクが大きいといわれています。
講師の桐山さんが大好きなお城である松本城にちなんで城攻めにたとえ、「外部からの脅威が脆弱性がある侵入経路を通ってお城に入りこみ、お城の中の情報資産を壊したり盗んだりする」と説明されました。なお、お城には、内在する脅威があることもあります。
リスク要因の管理可能性
上で挙げた3つのセキュリティリスク要因をみると、脆弱性に対処するのがよいことは明らかです。
外部からやってくる脅威の管理は困難です。また、情報資産の重要度はビジネス側の要請できまるため、リスクを減らすためといって資産価値を減じるわけにはいきません。たとえば、社として個人情報を持ちたくなくても、カード決済が必要なシステムがあれば、持たざるをえません。また、研究開発拠点で、知的財産を持たないわけにはいきません。
一方、脆弱性は社内にあるため、対応可能といえます。
脆弱性診断の種類 (レイヤー)
一口に脆弱性を診断するといっても、いくつか種類があります。想定する脆弱性攻撃の種類によって、どのレイヤーで対策が必要かを表で示します（講師によると、分類はあえて簡単にしてあるとのことです）。
| 脆弱性攻撃 | 対策 | レイヤー |
|---|---|---|
| SQLインジェクション、クロスサイトスクリプティング、OSコマンドインジェクション、パラメータ改ざん | WAF | Webアプリケーション |
| エクスプロイト、DoS攻撃 | IPS | OS/ミドルウェア |
| ポートスキャン | Firewall | ネットワーク |
上の表のうち、Webアプリケーションのレイヤーを診断するものをWebアプリケーション診断、OS/ミドルウェアとネットワークのレイヤーを診断するものをプラットフォーム診断と呼んでいます。
脆弱性診断の種類 (トポロジー)
今度は、脆弱性診断をトポロジー (ネットワーク接続形態) の観点から分類してみましょう。
診断対象サーバーは、イントラネットの特定のサブネット内にあると想定します。
- 外部ネットワーク型診断
- 外部からインターネット、イントラネットのファイアウォールを経由して診断する
- 内部ネットワーク型診断
- 診断対象サーバーと同じサブネット内にある別ホストから診断する
- ホスト型診断
- 診断対象サーバーの中に診断用エージェントをインストールし、エージェントが診断する
トポロジーで分類された脆弱性診断ごとに、目的、想定する脆弱性、実施タイミングの例が、表にまとめられていました。次のスライドを参照ください。
Amazon Inspectorとは
ここまでの基本的な知識を前提に、Amazon Inspectorについて解説されました。
一言でまとめると、Amazon Inspectorがおこなうセキュリティ診断は、EC2にエージェントを導入してプラットフォームの脆弱性を診断するホスト型診断サービスです。
Amazon Inspectorの特長
Amazon Inspectorは、AWSリソースに対するオンデマンド（＝事前申請いらず）の自動的（＝繰り返し再利用可能）で詳細な（＝推奨する対応方法を教えてくれる）セキュリティ評価サービスです。
Amazon Inspectorを利用する場合は、セキュリティ診断を実施する前に、AWSへの申請が不要です。通常の侵入テストは、事前にAWSに申請し、許可を得てから実施する必要があります。
Amazon Inspectorが提供するもの
- システム設定や振る舞いの分析エンジン
- 組み込みルールパッケージ (後述)
- 推奨対応手順が含まれた詳細レポート
- API連携による開発プロセスとの統合
ルールパッケージ
ルールパッケージとは、Amazon Inspectorが脆弱性診断をする際に照合するルールセットのことです。現時点では、次の4種類のルールパッケージが提供されています。
ルールパッケージ: CVE
CVE (Common Vulnerabilities and Exposures) とは、OpenSSLやサードパーティベンダーの製品など、個別の製品の脆弱性を管理した情報です。MITRE社が、脆弱性に「CVE-西暦4桁-連番」のフォーマットで採番して管理しています。
Amazon Inspectorでは、次のリストに掲載されたCVEの脆弱性にEC2インスタンスがさらされているかを評価します。現時点で4万件以上が掲載されています。
- https://s3-us-west-2.amazonaws.com/rules-engine/CVEList.txt
上のリストはAWSによって定期的に自動更新されるため、利用者は新しく発表されたCVEを追加するといった管理の手間から解放されます。
ルールパッケージ: CIS
CIS (Center for Internet Security)は、USのインターネットセキュリティ標準化団体が定めるOSセキュリティ設定のベンチマークです。
AWS Marketplaceでは、CISに準拠したAMIが、ベンダーから提供されています。
このルールパッケージは、現時点ではAmazon Linux 2015.03以降にのみ適用できます。
ルールパッケージ: セキュリティのベストプラクティス
これは、「SSH経由のrootログインを無効化する」「パスワードの複雑さを設定する」といった、セキュリティのベストプラクティスを定義したルールパッケージです。
診断の結果、違反している項目があった場合は、レポートに重要度が表示されます。
このルールパッケージは、現時点ではLinuxベースのOSにのみ適用できます。
ルールパッケージ: 実行時の振る舞い分析
これは、安全でないクライアントプロトコルでのログインや一般操作、未使用だがListenしているTCPポートなど、振る舞い分析を定義したルールパッケージです。
このルールパッケージも、診断の結果、違反している項目があった場合は、レポートに重要度が表示されます。
次のルールは、LinuxベースのOSにのみ適用されます。それ以外のルールは、Windows/Linux両方に適用されます。
- データ実行防止(DEP)のないソフトウェア
- スタックCookieがないソフトウェア
- 安全でないアクセス権限を持つrootプロセス
Amazon Inspectorの利用手順
インストール、実行、分析の手順に沿って、Amazon Inspectorを初期設定する手順が紹介されました。
1. インストール
1.1. 前提条件
- IAMロールを作成する
- デフォルトで用意されるIAMロールを使用してもかまいません
- EC2にタグを付加する
- Amazon Inspectorが診断対象のEC2インスタンスを識別できるように、任意のタグを付与します
- AWSエージェントをEC2インスタンスへインストールする -- LinuxベースのOSであれば、EC2内からwgetでイメージを取得してインストールします -- Windowsの場合も、ダウンロードしてインストールできます
1.2. 評価ターゲットの定義
評価ターゲットとは、脆弱性診断の対象とするAWSリソースの集合です。
- 評価ターゲットに名前を設定する
- 評価ターゲットにタグを設定する
- 1で診断対象のEC2に設定したものと同じタグを設定します
1.3. 評価テンプレートの定義
評価テンプレートとは、脆弱性診断をどのルールパッケージで、どれくらいの時間をかけておこなうかを定義したものです。
- 評価テンプレートに名前を設定する
- ルールパッケージを選択する
- 所要時間を設定する
- 特別な事情がなければ「推奨」と表記された時間を選びます
- 推奨より短い時間を選んだ場合、その時間内に評価できる項目しか診断されないため、場合によっては診断が不十分になるかもしれません
1.4. 設定の確認
これまでの設定内容を確認し、作成ボタンを押します。これでインストールが完了します。
2. 評価の実行
インストールが完了したら、評価テンプレートを選択して「実行」ボタンを押します。ステータスが「データを収集中」になり、評価がはじまります。
3. 分析
3.1. 分析結果の表示
重要度別に結果が一覧表示されます。
3.2. 推奨事項の確認
分析結果レコードを1件ずつ確認します。診断結果、重要度、説明、推奨事項が表示されます。
推奨事項とは: たとえば、脆弱性が発見されてパッケージのアップデートが推奨される場合は、その旨とパッケージ名やパッケージ配布元のリンクなどが表示されます。
Amazon Inspector 概要図
上の図は、Amazon InspectorがEC2を診断して、結果を外部から参照したり、診断実施をログ出力したりする通信を示しています。診断対象EC2に、AWSエージェントがインストールされています。
- 診断対象EC2からAmazon InspectorサービスとS3バケットに通信する
- EC2からAmazon Inspectorへテレメトリー情報（発見された脆弱性、稼働中のプロセス、インストールされているモジュールのバージョンなど）を送信します
- EC2からS3バケットへ接続して、エージェントの更新イメージを取得し、自動更新します。この通信は、エージェントの更新タイミングでのみ発生します
- 診断結果はAmazon Inspectorへ接続して取得する
- 管理コンソールからAmazon Inspectorダッシュボードにアクセスして、評価レポートを参照する
- AWS APIからAmazon Inspectorに接続して情報を得る
- Amazon InspectorがCloudTrailとSNSに情報を送信する (オプション)
- Amazon Inspectorの起動時にAPIの呼び出しログを記録する
- 評価の開始・終了・診断レポート出力をSNSで通知できる
AWSエージェント要件
Amazon Inspectorを利用すると上の図のような通信が発生するため、AWSエージェントをインストールする診断対象サーバーには、次の要件があります。
- パブリックなエンドポイントへアクセスできること
- Amazon IsnpectorとAmazon S3のサービスエンドポイント
- 診断対象サーバーがプライベートサブネットにある場合は、NAT Gatewayを経由することなどが必要になることも
- サービスエンドポイントとのTLS通信
- すべての接続はAWSエージェント側からのアウトバウンド通信で確立する（Security Groupでインバウンド通信を許可する必要はない）
- 経路中にプロキシサーバーがある場合は、現時点では利用できない
- エージェントのインストールにはOS管理者権限が必要
- AWSエージェントのサポートOS、使用可能リージョン
- Amazon Inspector料金
- 1エージェントに対する評価回数に対して料金が設定されている
- 10エージェントによる1回の評価も、1エージェントによる10回の評価も、10評価
- 評価回数が増えるほど1評価あたりの値段は安くなる
Amazon Inspectorの効率的な使い方
継続的なデプロイ＋セキュリティ評価 @設計開発時
継続的デプロイにセキュリティ評価を加える使い方です。
- 開発者がバージョンコントロールサーバにコードをコミットする
- CIでコードを取得して、分散ビルドする
- パッケージビルダーがアプリケーションをビルドして各種用途のサーバにデプロイする
- このタイミングで、デプロイ完了イベントをフックしてAmazon Inspectorの評価APIを呼び出し、インスタンスの評価を自動実行する
- 評価レポートをSNS経由で開発者に送る
セキュリティの自動拡張 (Security at Scale) @本番運用時
Auto Scalingの起動時設定に組み込む使い方です。環境内のセキュリティが維持されるので、セキュリティそのものもスケールすると呼んでいました。
- Auto Scalingグループの起動設定で、AWSエージェントのインストールを定義しておく
- スケールアウトでインスタンスが起動すると、AWSエージェントがインストールされる
- Auto ScalingのグループタグをAmazon Inspectorの評価ターゲットに設定することで、スケールしたインスタンスも自動セキュリティ評価の対象にできる
評価結果対応の簡易ワークフロー @開発時でも本番でも
脆弱性診断の結果への対応を、組織のワークフローに載せて管理するためのtipsです。
評価結果のレコードに属性（キーと値）を追加して、対応処理の簡易ワークフローに利用します。
- 設定例
- キー=「状況」、値=緊急度（「緊急」、「対応済み」など）
- キー=「担当者」、値=個人名（「横田」など）
- 使い方: 「担当者」属性の値に自分の名前が設定された評価結果レコードをピックアップし、対応が完了したら「状況」属性の値を「対応済み」に変更しておく
また、属性は評価テンプレート選択時にも設定できるので、たとえば、CVEルールパッケージによって検出された脆弱性への対応を、特定のチームにアサインするようなことが表現できます。
- 設定例
- キー=「担当者」、値=特定のチーム（「基盤チーム」など）
まとめ
- Amazon Inspectorは、ホスト型のプラットフォーム脆弱性診断
- オンデマンド（＝事前申請いらず）、自動的（＝繰り返し再利用可能）、詳細（＝推奨する対応方法を教えてくれる）
- 開発環境でも本番環境でも、いつでも何度でも簡単に使える
参考資料
- メインページ: Amazon Inspector
- クイックスタート: Amazon Inspector Quickstart Walkthrough - Amazon Inspector
- FAQ: Amazon Inspector | FAQs
- 料金: Amazon Inspector | Pricing
- お客様の声: Amazon Inspector | Customers
- パートナー: Amazon Inspector | Partners
Q&A
- 質問. CVEの公開からAmazon Inspectorのリスト更新までのタイムラグはどれくらいですか。
- 回答. AWSは、脆弱性への対応情報をSecurity Bulletinsで公開しています。特に世の中にインパクトの大きい脆弱性の場合は、脆弱性が公開されたその日のうちに対応することが多いです。将来的なCVEの更新対応を約束するものではありませんが、AWSとしては、それくらいの時間感覚で動いています。
- 質問. 評価の所要時間をあえて短く設定するのは、どういった場合が考えられますか。
- 回答. 推奨時間を選択いただくのがあくまでも最良です。ただし、評価結果がすぐに失敗に終わる可能性がある場合には、所要時間を短く設定することがあるかもしれません。たとえば、あるルールパッケージがサポートしていないOSバージョンが診断対象に含まれることが分かっている場合、15分などの短時間に設定したほうが、結果が早く得られてよいのではないでしょうか。
- 質問. 1つの評価テンプレートに複数のルールパッケージを選択してもよいのでしょうか。
- 回答. はい、できます。たとえば、1つのパッケージにCVEもCISも選べます。
また、Amazon WAFとの連携、評価レポートのJSON出力、セキュリティパッチの自動適用のAPI連携などに需要があれば、Amazon Inspector活用の上級者向けのセミナーを開催してくれるそうです。興味のある方は、ハッシュタグ#awsblackbeltをつけて「松本城」とtweetしましょう。
おわりに
初級者向けということで、非常にわかりやすい説明でした。
利用しているAWS環境の最低限のセキュリティを底上げするサービスとして、Amazon Inspectorを定期的に回していけると理想的ですね。
それでは、また。
