GOST R 57580 とコンテナ仮想化を友達にする方法。 中央銀行の対応（およびこの件に関する私たちの考え）

少し前に、当社は GOST R 57580 (以下、単に GOST と呼びます) の要件への準拠に関する別の評価を実施しました。 クライアントは電子決済システムを開発する会社です。 このシステムは本格的で、ユーザー数は 3 万人を超え、毎日 200 万件以上のトランザクションが行われています。 そこでは情報セキュリティを非常に重視しています。

評価プロセス中に、クライアントは、開発部門が仮想マシンに加えてコンテナを使用する予定であることを何気なく発表しました。 しかし、これには問題が XNUMX つあるとクライアントは付け加えました。GOST には同じ Docker についての記述がありません。 どうすればいいですか？ コンテナのセキュリティを評価するにはどうすればよいですか?

確かに、GOST はハードウェア仮想化、つまり仮想マシン、ハイパーバイザー、およびサーバーを保護する方法についてのみ書いています。 私たちは中央銀行に説明を求めました。 その答えは私たちを困惑させました。

GOSTと仮想化

まず、GOST R 57580 は「金融機関の情報セキュリティを確保するための要件」(FI) を規定した新しい規格であることを思い出してください。 これらの金融機関には、決済システムの運営者と参加者、信用組織と非信用組織、運用センターと清算センターが含まれます。

1 年 2021 月 XNUMX 日から、金融機関は次のことを行うことが義務付けられます。 新しいGOSTの要件への適合性の評価。 私たちITGLOBAL.COMは、そうした評価を行う監査会社です。

GOST には、仮想化環境の保護に特化したサブセクション (No. 7.8) があります。 ここでは「仮想化」という用語は指定されておらず、ハードウェア仮想化とコンテナ仮想化に分けられていません。 IT 専門家なら誰でも、技術的な観点からこれは間違いだと言うでしょう。仮想マシン (VM) とコンテナーは異なる環境であり、分離原則も異なります。 VM と Docker コンテナがデプロイされるホストの脆弱性の観点から見ると、これも大きな違いです。

VM とコンテナーの情報セキュリティの評価も異なるはずであることがわかりました。

中央銀行への質問

私たちはそれらを中央銀行の情報セキュリティ部門に送りました（質問は省略形で提示されています）。

1. GOST 準拠を評価する際に、Docker タイプの仮想コンテナをどのように考慮すればよいですか? GOST の第 7.8 条に従って技術を評価するのは正しいですか?
2. 仮想コンテナ管理ツールを評価するにはどうすればよいですか? それらをサーバー仮想化コンポーネントと同等視し、GOST の同じサブセクションに従って評価することは可能ですか?
3. Docker コンテナ内の情報のセキュリティを個別に評価する必要がありますか? そうである場合、評価プロセス中にこれに対してどのような保護措置を考慮する必要がありますか?
4. コンテナ化が仮想インフラストラクチャと同等であり、サブセクション 7.8 に従って評価される場合、特別な情報セキュリティ ツールの実装に関する GOST 要件はどのように実装されますか?

中央銀行の対応

以下、主な抜粋です。

「GOST R 57580.1-2017 は、GOST R 7.8-57580.1 の次の措置 ZI サブセクション 2017 に関連する技術的措置の適用による実装要件を確立しています。同省の意見では、これはコンテナ仮想化を使用する場合にも拡張できると考えています」以下を考慮してテクノロジーを検討します。

• 仮想マシンおよび仮想化サーバーコンポーネントへの論理アクセスを実装する際の識別、認証、認可（アクセス制御）を組織化するための対策 ZSV.1 ～ ZSV.11 の実装は、コンテナ仮想化テクノロジーを使用する場合とは異なる場合があります。 これを考慮すると、多くの措置 (ZVS.6 や ZVS.7 など) を実施するために、金融機関が同じ目標を追求する補償措置の開発を推奨することが可能であると考えられます。
• 仮想マシンの情報相互作用の組織化および制御のための対策 ZSV.13 ～ ZSV.22 の実装は、仮想化テクノロジーを実装し、異なるセキュリティ回路に属する情報化オブジェクトを区別するために、金融組織のコンピュータ ネットワークのセグメント化を提供します。 これを考慮すると、コンテナ仮想化テクノロジを使用する場合は (実行可能な仮想コンテナとオペレーティング システム レベルで使用される仮想化システムの両方に関して) 適切なセグメンテーションを提供することが賢明であると考えられます。
• 仮想マシンのイメージの保護を組織化するための対策 ZSV.26、ZSV.29 ～ ZSV.31 の実装は、仮想コンテナの基本イメージと現在のイメージを保護するためにも同様に実行される必要があります。
• 仮想マシンおよびサーバー仮想化コンポーネントへのアクセスに関連する情報セキュリティ イベントを記録するための対策 ZVS.32 ～ ZVS.43 の実装は、コンテナ仮想化テクノロジを実装する仮想化環境の要素に関しても同様に実行される必要があります。」

どういう意味ですか

中央銀行情報セキュリティ部門の回答から得られた主な結論は次の XNUMX つです。

• コンテナを保護するための対策は、仮想マシンを保護するための対策と何ら変わりません。
• このことから、中央銀行は情報セキュリティの文脈において、Docker コンテナと VM という XNUMX 種類の仮想化を同一視していることがわかります。

この回答では、脅威を無力化するために適用する必要がある「代償措置」についても言及されている。 これらの「代償措置」が何なのか、またその適切性、完全性、有効性をどのように測定するかは不明です。

中央銀行の立場の何が間違っているのでしょうか？

評価 (および自己評価) 中に中央銀行の推奨事項を使用する場合、多くの技術的および論理的問題を解決する必要があります。

• 各実行可能コンテナには、ウイルス対策、整合性監視、ログの操作、DLP システム (データ漏洩防止) などの情報保護ソフトウェア (IP) をインストールする必要があります。 これらはすべて VM に問題なくインストールできますが、コンテナーの場合、情報セキュリティをインストールするのは無謀な行為です。 コンテナには、サービスが機能するために必要な最小限の「ボディキット」が含まれています。 そこにSZIを取り付けることはその意味に矛盾します。
• コンテナ イメージは同じ原則に従って保護される必要がありますが、これを実装する方法も不明です。
• GOST では、サーバー仮想化コンポーネント、つまりハイパーバイザーへのアクセスを制限する必要があります。 Docker の場合、サーバー コンポーネントとは何ですか? これは、各コンテナを別のホストで実行する必要があることを意味するのではありませんか?
• 従来の仮想化では、セキュリティ輪郭とネットワーク セグメントによって VM を区切ることが可能ですが、同じホスト内の Docker コンテナの場合は当てはまりません。

実際には、各監査人が自身の知識と経験に基づいて、独自の方法でコンテナのセキュリティを評価する可能性があります。 まあ、どちらか一方がない場合は、まったく評価しないでください。

念のため、1 年 2021 月 0,7 日以降、最低スコアは XNUMX 以上でなければならないことを付け加えておきます。

ちなみに、当社では、GOST 57580 および中央銀行規制の要件に関連する規制当局からの回答やコメントを定期的に投稿しています。 電信チャネル.

何をすべきか

私たちの意見では、金融機関が問題を解決するための選択肢は XNUMX つしかありません。

1. コンテナの実装を避ける

ハードウェア仮想化のみを使用する余裕があり、同時に GOST による低い評価や中央銀行からの罰金を恐れている人向けのソリューション。

プラス： GOST の第 7.8 条の要件に準拠することが容易になります。

マイナス： コンテナ仮想化に基づく新しい開発ツール、特に Docker と Kubernetes を放棄する必要があります。

2. GOST の第 7.8 条の要件の遵守を拒否する

ただし同時に、コンテナーを使用する場合は、情報セキュリティを確保するためのベスト プラクティスを適用してください。 これは、新しいテクノロジーとそれが提供する機会を重視する人のためのソリューションです。 「ベスト プラクティス」とは、Docker コンテナのセキュリティを確保するために業界で認められた規範と標準を意味します。

• ホスト OS のセキュリティ、適切に構成されたロギング、コンテナ間のデータ交換の禁止など。
• Docker Trust 機能を使用してイメージの整合性をチェックし、組み込みの脆弱性スキャナーを使用します。
• リモート アクセスとネットワーク モデル全体のセキュリティを忘れてはなりません。ARP スプーフィングや MAC フラッディングなどの攻撃はまだキャンセルされていません。

プラス： コンテナ仮想化の使用には技術的な制限はありません。

マイナス： GOST要件の不遵守に対して規制当局が罰則を科す可能性が高い。

まとめ

私たちのクライアントはコンテナを手放さないことに決めました。 同時に、作業範囲と Docker への移行のタイミングを大幅に再考する必要がありました (移行には 57580 か月かかりました)。 クライアントはリスクをよく理解しています。 彼はまた、GOST R XNUMX への準拠性の次回の評価では、多くのことが監査人に依存することも理解しています。

この状況であなたならどうしますか？

出所： habr.com