評価の過程で、クライアントは、仮想マシンに加えて、開発部門がコンテナの使用を計画していると何気なく言った。しかし、これに伴い、クライアントは追加しました。1つの問題があります。GOSTには同じDockerについての言葉がありません。どうなる？コンテナの安全性を評価する方法は？
確かに、GOSTはハードウェアの仮想化についてのみ、つまり仮想マシン、ハイパーバイザー、サーバーを保護する方法についてのみ述べています。私たちは中央銀行に説明を求めました。答えは私たちを困惑させた。
GOSTと仮想化
まず、GOST R 57580は、「金融機関の情報セキュリティを確保するための要件」（FO）を詳しく説明した新しい標準であることを思い出してください。これらのFIには、支払いシステムの運営者と参加者、クレジット機関と非クレジット機関、運用センターと清算センターが含まれます。
2021年1月1日以降、FDは2年ごとに新しいGOST要件への準拠を評価する必要があります。私たちITGLOBAL.COMは、そのような評価を行う監査会社です。
GOSTには、仮想化環境の保護専用のサブセクションがあります-No.7.8。ここでは「仮想化」という用語は指定されておらず、ハードウェアとコンテナの仮想化に分類されていません。ITスペシャリストなら誰でも、技術的な観点からはこれは正しくないと言うでしょう。仮想マシン（VM）とコンテナは異なる環境であり、分離の原則も異なります。VMとDockerコンテナがデプロイされているホストの脆弱性の観点からも、これは大きな違いです。
VMとコンテナの情報セキュリティ評価も異なる必要があることがわかりました。
私たちの質問中央銀行
中央銀行の情報セキュリティ部に送付しました（質問は省略形で記載しています）。
- GOSTコンプライアンス評価を実施する際にDockerタイプの仮想コンテナをどのように検討しますか？GOSTのサブセクション7.8に従ってテクノロジーを評価することは正しいですか？
- 仮想コンテナコントロールを評価するにはどうすればよいですか？それらを仮想化のサーバーコンポーネントと同一視し、同じGOSTサブセクションに従って評価することは可能ですか？
- Dockerコンテナ内の情報のセキュリティを個別に評価する必要がありますか？もしそうなら、評価プロセスでどのような保護手段を検討する必要がありますか？
- コンテナ化が仮想インフラストラクチャと同等であり、サブセクション7.8に従って評価される場合、特別な情報セキュリティツールの実装に関するGOST要件はどのように実装されますか？
中央銀行の対応
以下は主な抜粋です。
「GOSTR57580.1-2017は、GOST R 57580.1-2017のサブセクション7.8のZIの次の測定値に関連する技術的測定値を適用することにより、実装の要件を確立します。これは、部門によれば、以下を考慮して、コンテナ仮想化テクノロジを使用する場合に拡張できます。
- .1 – .11 , , ( ) . (, .6 .7) , ;
- .13 – .22 , , . ( , );
- .26, .29 – .31 ;
- 仮想マシンおよび仮想化のサーバーコンポーネントへのアクセスに関連する情報セキュリティイベントの登録に関する対策ZVS.32-ZVS.43の実装は、コンテナ仮想化のテクノロジを実装する仮想化環境の要素に関して類推して実行する必要があります。」
どういう意味ですか
中央銀行の情報セキュリティ部門の回答からの2つの主な結論：
- コンテナを保護するための対策は、仮想マシンを保護するための対策と同じです。
- このことから、情報セキュリティのコンテキストでは、中央銀行は2つのタイプの仮想化（DockerコンテナとVM）を同一視していることになります。
回答には、脅威を中和するために適用する必要のある「補償措置」についても言及されています。ただし、これらの「補償手段」とは何か、それらの妥当性、完全性、および有効性をどのように測定するかは明確ではありません。
中央銀行の立場の何が問題になっていますか
中央銀行の推奨事項を評価（および自己評価）に使用する場合、技術的および論理的な問題の数を解決する必要があります。
- 実行可能な各コンテナには、情報セキュリティソフトウェア（SSS）をインストールする必要があります。アンチウイルス、整合性制御、ログの操作、DLPシステム（データリーク防止）などです。これはすべて問題なくVMにインストールできますが、コンテナーの場合、SZIのインストールはばかげた動きです。コンテナには、サービスが機能するために必要な最小限の「ボディキット」が含まれています。その中に情報セキュリティシステムをインストールすることは、その意味と矛盾します。
- 同じ原則で、コンテナイメージを保護する必要があります。これを実装する方法も不明です。
- , . . . Docker? , ?
- , Docker- — .
実際には、各監査人は、知識と経験に基づいて、独自の方法でコンテナの安全性を評価する可能性があります。まあ、またはまったくない場合は、どちらもありません。
念のため、2021年1月1日から、最小見積もりは少なくとも0.7でなければならないことを追加します。
ちなみに、GOST 57580の要件や中央銀行の規制に関連する規制当局の回答やコメントは、テレグラムチャネルに定期的に掲載しています。
何をすべきか
私たちの意見では、金融機関には問題を解決するための2つの選択肢しかありません。
1.コンテナの実装を拒否する
ハードウェア仮想化のみを使用する余裕があり、同時に低いGOST評価と中央銀行の罰金を恐れている人のためのソリューション。
さらに、GOSTのサブセクション7.8の要件を満たす方が簡単です。
短所：コンテナ仮想化に基づく新しい開発ツール、特にDockerとKubernetesを放棄する必要があります。
2.GOSTのサブセクション7.8の要件を満たすことを拒否する
しかし同時に、コンテナを操作する際の情報セキュリティを確保するためのベストプラクティスを適用すること。これは、新しいテクノロジーとそれらが提供する機会にもっと興味がある人のためのソリューションです。「ベストプラクティス」とは、ここでは、Dockerコンテナの安全性を確保するために業界で採用されている基準と標準を意味します。
- ホストOSのセキュリティ、適切に構成されたロギング、コンテナ間のデータ交換の禁止など。
- Docker Trust機能を使用して画像の整合性をチェックし、組み込みの脆弱性スキャナーを使用します。
- リモートアクセスのセキュリティと一般的なネットワークモデルを忘れてはなりません。ARPスプーフィングやMACフラッディングなどの攻撃をキャンセルした人は誰もいません。
さらに、コンテナ仮想化の使用に関する技術的な制限はありません。
マイナス：規制当局がGOST要件への違反を罰する可能性が高いです。
結論
私たちのクライアントは、コンテナをあきらめないことに決めました。同時に、彼は作業の範囲とDockerへの移行のタイミングを大幅に修正する必要がありました（6か月間延長されました）。クライアントはリスクを十分に認識しています。彼はまた、GOST R 57580との次の適合性評価中に、多くが監査人に依存することを理解しています。
この状況であなたは何をしますか？