PCI DSS要件のある環境で自己管理の内部診断としてAmazon Inspectorを活用する方法

PCI DSS要件11.2で活用できる脆弱性診断サービスのAmazon Inspectorについて、QSAと協議した知見を共有します。Inspectorの使い方や特徴を踏まえ、どのようにPCI DSSの要件を満たしていくか解説します。
2019.07.01

この記事は公開されてから1年以上経過しています。情報が古い可能性がありますので、ご注意ください。

こんにちは、臼田です。

AWSには様々なサービスがあり、オンプレミス基盤でやっていたPCI DSS要件への対応についてを任せられるサービスも沢山あります。 それぞれのサービスは、AWSから提供される時点でプラットフォームとしてのPCI DSS等各種監査基準をクリアしており、そのためのインフラを管理しなくていいことも魅力です。

今回はそんな中で内部脆弱性診断の仕組みとして利用できるAmazon Inspectorについて、とあるQSAとディスカッションしてきた知見をベースに、使い方や実環境での活用方法をまとめます。※QSA(Qualified Security Assessors:認定セキュリティ評価機関, PCISSCに認定されたセキュリティ監査企業のこと)

Amazon Inspectorとは

概要

Amazon Inspectorは一言で言うと脆弱性診断のサービスです。

AWS上でユーザが行う脆弱性の管理は主にEC2上のOS以上のレイヤーに対して責任を負いますが、InspectorではEC2にエージェントをインストールし、ホスト型で脆弱性診断を行うことが出来ます。

診断できる内容の代表格は共通脆弱性識別子(CVE)ですが、それ以外にもCISベンチマークやセキュリティベストプラクティス、ネットワークの到達可能性なども合わせて評価が可能です。

全体の動作像

AWSの無料オンラインセミナーBlackbeltの資料より引用しています。

InspectorのエージェントはEC2から上りの通信でInspectorのエンドポイントにHTTPSで通信するため、下りの穴あけが必要なく非常に管理がしやすいです。診断の指示や、診断結果の収集は全てこの上りの通信をトリガーに実施されます。

Inspectorのサービス自体はAWSのマネージドサービスとなりますので、脆弱性診断を行うための基盤の管理などは不要なため、運用負荷が低減されます。

対応OS

AWSで活用される主要なOSは網羅されています。具体的には下記になります。

  • Amazon Linux
  • Amazon Linux 2
  • Ubuntu
  • Debian
  • RHEL
  • CentOS
  • Windows Server

ドキュメントはこちらです。

価格

評価の回数ベースの従量課金で、非常に安価に利用できます。価格表はこちらにあります。簡単に書くと下記のようになります。

  • 無料トライアル
    • Amazon Inspector の利用開始から 90 日間
    • 最初の 250 回のインスタンス評価: 0.00 USD
  • 料金詳細
    • 1 回のインスタンス評価ごとの料金(月毎)
    • 最初の 250 回のインスタンス評価: 0.30 USD
    • 以降、一定回数毎にディスカウント

例えば10台のインスタンスを毎日診断したとします。

0.30 USD * 10台 * 30日 = 90 USD

月額 90 USDで10台の脆弱性を管理できると考えると安価であることがよく分かるかと思います。

詳細な使い方

下記をご参照ください。

Amazon Inspector を使って毎月自動で EC2 インスタンスのセキュリティ評価を実施する

PCI DSS要件の中での活用方法

PCI DSSの要件11.2では四半期ごとの内部脆弱性スキャンが必要とされていて、こちらにInspectorを活用することができます。

同じ要件内の外部脆弱性スキャンについてはASVによる実施が必要ですが、内部についてはその必要がないため、Inspectorを自分たちで回していく体制を作ることで対応していくことが可能です。(厳密には、実施に当たっては、脆弱性に対する知見を有し、かつ組織上独立性をもった立場の担当者での実施が求められます。)※ASV(Approved Scanning Vendors :認定スキャニングベンダー)

Inspectorを活用した脆弱性ハンドリングのイメージ

定期実行

Inspectorはスケジューリングをして定期的に実行できます。四半期に1回でもいいですが、脆弱性は常に発生し続けるためデイリーやウィークリーでの定期実行を仕込んでおき、常に最新の診断結果を確認するほうがいいでしょう。

レポートの確認

診断が終わるとレポートを出力することが可能です。下記のようにCVEの中で重要度のレベル別のサマリがあり、その後検知した脆弱性の詳細があります。

脆弱性のハンドリング

基準の設け方によりますが、例えばInspectorから「High」と判断された脆弱性については全て対応するようなポリシーとしている場合(要件6.1での定義)は上記表に従ってHighのものを対処すればいいでしょう。

Inspectorがつける基準以外にも、CVSS2や3のScoreを出力することも可能なので、こちらの値をベースに対応の優先順位をつけてもいいです。こちらの場合はレポートではなく、AWSマネジメントコンソール上からCSV出力することにより確認が可能です。

パッチ適用

従来どおりサーバに直接接続してパッチの適用を行う運用でも構いませんが、せっかくAWS環境なのでもう少し便利な方法を活用することも検討していただくといいでしょう。

AWS Systems Manager(SSM)ではパッチマネージャーという機能があり、こちらから指定したEC2に対して一括でパッチの適用を行うことが可能です。

【アップデート】Amazon EC2 Systems ManagerのPatch ManagerがLinuxに対応しました!!!

こちらを活用すると、OSにログインする必要がなく、パッチの適用以外の操作を実行することもないのでオペレーションの負荷軽減やミスを無くす効果が期待できます。

各フローの自動化

これは発展的なイメージですが、上記パッチマネージャー等のAWSサービスを組み合わせると、脆弱性の検知から是正まで自動的に回すことも可能です。

自動化する場合には、テストフローも用意して、検証環境から回す必要がありますが、うまくできれば大きく運用負荷が軽減でき、品質も保ちやすくなるでしょう。

例えば下記のように、EC2を1台ずつ自動的にメンテナンスしていくような手法を取ることも可能です。

AutoScalingで1台ずつ自動的にパッチを当てるSSM Automationやってみた

 

なお、ここまで上げさせていただいた活用法はあくまで一つの想定環境での話のため、PCI DSSの要件に適用できるかどうかはQSAに相談してみてください。

まとめ

AWS上で利用できる脆弱性診断サービスのAmazon Inspectorについて、使い方や特徴と、PCI DSSの要件11.2の内部脆弱性診断に対応するための活用方法をご紹介しました。

内部での脆弱性診断や管理は課題になることが多いと思いますが、うまく使えるサービスを活用して運用負荷の軽減や高速化、品質の向上などを図ってみてはいかがでしょうか?

また、ご紹介した内容はあくまで一例に過ぎず、APIでInapectorの各種操作が可能なため連携の幅は広いです。もっと自由にAWSを活用して自動化や負荷軽減を促進しましょう。