/写真NTNU CC
誰が認証を必要としますか？
標準の要件は、少なくとも1つのクレジットカードのデータを処理、転送、または保存するすべての企業に適用されます。 以前の記事の1つで、PCI DSS認定が必要な人を理解するのに役立つ簡単なフローチャートを提供しました。
その本質は、組織の経営者がこれらの質問に答えるのに十分であるということです：
- 会社はPDカード所有者と協力していますか？
- 会社の作業プロセスは、カードデータの安全性とセキュリティに影響しますか？
これらの両方の質問に対する答えが「はい」である場合、会社は認定される必要があります。 PCI DSSに違反した場合、組織は以下に応じて10〜20万ドルの罰金を支払う必要があります 。
- 支払いシステムのタイプ（VisaまたはMasterCard）;
- 会社のステータス（メンバー、サービスプロバイダー、または貿易組織）;
- 違反の再現性（最初、2番目以降）。
2015年に初めてPCI DSSを認証したのは、標準の要件への準拠について監査された最初のクラウドプロバイダーの1つです。
次に、このプロセスがどのように行われたかを説明します。
ステージ1：ドキュメントの準備
監査を受ける前に、会社は情報セキュリティに関する規制および管理文書（指示、規制、ポリシー）を準備する必要があります。 最初の認証の時点で、それらのほとんどはすでに当社によって開発されていましたが、一部はまだ確定する必要がありました。
たとえば、企業の情報セキュリティを確保するための目標、目的、方法を含むポリシーを編集する必要がありました。 また、脆弱性とインシデントを管理するための原則を定義する規制を改訂しました。 たとえば、「情報資産へのアクセスを管理するための規則」を作成しました。これは、アクセス権を使用するための規則とユーザー資格情報の要件を説明しています。
すべての文書は毎年見直され、調整されなければならないことに注意してください。 特に、会社のIT構造に変更があった場合。
ステージ2：ITインフラストラクチャの構築
次のステップは、インフラストラクチャの準備です。 組織が初めて監査される場合、管理者は認証される範囲を決定する必要があります。つまり、認証の対象となるすべてのプロセスをサポートする個別のインフラストラクチャユニットを制限する必要があります。 これは、標準の要件に準拠するための新しいテストでインフラストラクチャの変更を伴う必要がないようにするために必要です。
そのためには、専用ネットワークを備えた個別のインフラストラクチャを編成し、ESX、vSphere、vCenterサーバーを展開し、スイッチとファイアウォールをインストールして攻撃者を防ぐ必要がありました。 このすべての機器を複製し、サービス、ネットワーク、ビジネスプロセスの図を作成しました。
認定インフラストラクチャは、組織の他のネットワークから分離する必要があります-インフラストラクチャへのアクセスは、隔離されたインターフェイスを介して提供する必要があります。 この要件を満たすために、2FAでVPNを使用し、各クライアントのセグメントを分離します。
境界内には、NTPサーバー、ログサービス、ウイルス対策、ファイアウォール、およびサイバー攻撃を防ぎ、データの安全性を制御するソリューションがあります。 こちらのネットワーク図をご覧ください 。
ステージ3：ペンテスト
ペンテストは 、監査会社に代わって特別なチームによって実施されます。 監査人は、カード所有者のデータを保護するために使用されるソリューションの動作を確認し、潜在的なセキュリティホールを特定します。
インフラストラクチャの侵入抵抗を確認する前に、チームは 2つのミサゴを準備しました 。 テストに関係するサービスサービスとアプリケーションを備えた最初のもの。 2番目では、OSを備えたVMが構成され、必要な権限が対応するアカウントに割り当てられました。
/ホストされたサービスとアプリケーションを備えたミサゴの例
インフラストラクチャのテストはいくつかの段階で実施されました。
Nmapスキャン
監査役は、当社のホワイトIPアドレスを確認しました。 パブリックIPアドレスを持つマシンでは、開いているポートを見つけることができませんでした（インフラストラクチャの機能を担当するポートのみが開いていました）。
VPN接続と内部ネットワークチェック
ペンテストチームは、信頼できないネットワークからアクセスしようとしました。 テスト結果は、2FAなしでVPNを介してIT-GRADインフラストラクチャに侵入することは不可能であることを示しました。 内部ネットワークを確認しても、違反は明らかになりませんでした。
アカウントによるインフラストラクチャ接続へのアクセスの試行
サードパーティのリソース （このリソースはiaas-blog.it-grad.ruでした）で、専門家が同僚の資格情報を取得しました。 この同僚は、テスト済みのIT-GRADインフラストラクチャにもアカウントを持っていました。 監査人は自分のアカウントとパスワードを使用してログインしようとしましたが、ネットワークが完全にセグメント化されていたため成功しませんでした。
監査の結果によると、合計で、重大度が異なる7つの脆弱性が見つかりました。1つの高レベルと3つの中レベルおよび低レベルの「危険」です。
最も重要な脆弱性-WAFの誤動作-は、使用されているファイアウォールが複雑な攻撃に対処できないために発生しました。 脆弱性を排除するために、Apache WebサーバーにModsecurityモジュールを展開し、WAF署名データベースを更新しました。
中間レベルには3つの脆弱性がありました。 1つ目は、含まれているTRACEメソッドです。これは、攻撃者がクロスサイトスクリプティングなどに使用できます 。 脆弱性を修正するために、TRACEメソッドを無効にしました。
2番目の不一致は、安全なHTTPヘッダーの欠如です。 脆弱性により、攻撃者がユーザーインターフェイスを攻撃する可能性があります。 対応するアプリケーションサーバーでセキュアヘッダーを有効にすることで、この問題を解決しました。
3番目の脆弱性は、ホストの1つにあるソフトウェアの脆弱性です（ソフトウェアの古いバージョンによる）。 この脆弱性を修正するために、すべてのノードで定期的なソフトウェアアップデートをセットアップします。
重大度の低い脆弱性の中で、監査員は本番環境でパスワードハッシュ付きのテストデータを見つけました。 彼らはまた、信頼できないパスワードと不必要なソフトウェアを指摘しました。 脆弱なパスワードを安全なパスワードに置き換え、未使用のデータとソフトウェアを削除しました。 すべての脆弱性を修正した後、繰り返しのペンテストに成功しました。
ステージ4：最終監査
監査の最終段階で、監査人はソフトウェアとハードウェアの完全性とパラメータ、ネットワークトポロジ、OS構成、インフラストラクチャセグメントの分離、およびその他の特性を評価します。 さらに、彼は従業員のドキュメントと知識をチェックし、組織的または技術的な性質の質問をすることができます。
会社が標準の要件からわずかな逸脱を示している場合、監査中にそれらを排除できます。 たとえば、Active Directoryで非アクティブなコンピューターアカウントが見つかりましたが、すぐに削除しました。
監査前または監査中に何かを変更する必要がある場合、これも問題ではありません。 ここでの主なことは、PCI DSSの必要に応じて変更を加えることです。
たとえば、監査の前に、IT-GRADではSFTPサーバー上のファイルのロードとアンロードを追跡する必要がありました。 これを行うには、avusmサーバーのデコーダーを緊急に作成する必要がありました。 デコーダーがないと、サーバーはログを「解析」してアラートを生成できなかったため、必要なメッセージを保存しませんでした。
最終的に、PCI DSSコンプライアンス証明書を受け取り、PCI DSSホスティングサービスを提供するロシアで最初のIaaSプロバイダーの1つになりました。
PS First Corporate IaaSブログのトピックに関する資料：