IS要件を満たすためにクラウドに移行する人をどのように支援するか

12月、Roskomnadzorのウェブサイトは来年の定期検査を掲載しました。 私たちは外国のソーシャルネットワークから始めましたが、今では極東の銀行と多くの企業が並んでいます。 すべてが順調に進んでいるわけではありませんが、チェックは近くで選択されています。 その結果、これにより、認定クラウドへの移行にある程度の関心が寄せられたため、FZ-149および152に準拠するものについて詳しく説明したいと思います。

また、連邦法-152への準拠の認定が誤って行われる方法も確認しました。 以下に、必ずしもそれが必ずしも必要ではない理由を説明します。

今では誰もが、自宅ではなくインフラストラクチャをラックの形で展開するときに何をする必要があるかを理解しています。 ロシア市場は、クラウドへの移行に関してあまり精通していません。 大規模な州の顧客は、クラウドテクノロジー（特に状態クラウド）が必要であることを直感的に理解していますが、これを行うために何をする必要があるかを理解していません。 このような状況に対応する準備ができており、情報セキュリティのコンピテンシーの特別センターがあります。 Technoservクラウドプラットフォームは、情報セキュリティ要件の認定を受けており、情報セキュリティの最高要件の対象となるGISおよびISPDnを配置できます。これは、クライアントのソリューションを認定することのみを目的としています。 私たちの助けを借りて、これは通常2〜3か月でなくなります。これははるかに高速です（通常、単独で6か月かかります）。

そのような手順を例として見てみましょう。 あなたが患者の個人データを非常に保護している医療会社だとします。

ライセンスと認証および認証との違いに関する短い教育プログラム：

• 保護装置（ソフトウェアおよびハードウェア）は認定されており、メーカーはFSBおよびFSTECから証明書を受け取ります。 このような証明書は、たとえば、暗号化が許可され、ソフトウェアにブックマークがなく、ロシアの標準が尊重されていることを示しています。
• 認定された「パーツ」を使用して組み立てられた完成品が認定されます。 認証とは、情報化の対象が一連の対策を正しく実行することの確認です。 つまり、コンストラクターは正しくアセンブルされます。 証明書はFSTECライセンシーによって発行されます。
• 情報セキュリティ活動は認可されています。 たとえば、テクノサーブはFSTECのライセンシーの1人であり、上記の段落から証明書を発行できます。

最初は難しい状況です。 あなたが大規模な州立医療機関であるとします。 キーワードは「状態」です。つまり、 GISケースがあります。 連邦法149は、情報の所有者と情報システムの運用者に対し、以下を目的とする法的、組織的、技術的措置を講じることにより、不正アクセス、破壊、修正、ブロック、コピー、提供、配布、その他の違法行為（第14条9項）から情報を保護することを義務付けていますアクセスが制限された情報の機密性の遵守、および公開されている情報にアクセスする権利の行使（第16条）。

まず、情報の重要性と起こりうる損害、情報システムの規模が評価されます。 医療システムについては、保護クラス（K 1）が割り当てられます-処理される個人データの指定されたセキュリティ特性に違反すると、個人データの対象に重大な悪影響が生じる可能性がある情報システム。

個人データはFZ-152によって規制されています。 ロシア連邦市民の個人データの処理の運営者である組織は、ロシア連邦の領土にあるデータベースを使用した個人データの記録、体系化、蓄積、保存、更新（更新、変更）、抽出を確実にする義務があります。

PDには、特別、バイオメトリック、パブリック、その他の4つのカテゴリがあります。 セキュリティレベルは次のようになります。

処理済みPD	PDボリューム	実際の脅威の種類
		タイプ1の脅威	タイプ2の脅威	タイプ3の脅威
特別なPDカテゴリー	10万人以上	KM 1	KM 1	KM 2
	10万未満	KM 1	KM 2	KM 3
オペレーターの従業員の個人データの特別なカテゴリー	どれでも	KM 1	KM 2	KM 3
生体認証PD	どれでも	KM 1	KM 2	KM 3
PDの他のカテゴリー	10万人以上	KM 1	KM 2	KM 3
	10万未満	KM 1	KM 3	KM 4
オペレーターの従業員の個人データの他のカテゴリ	どれでも	KM 1	KM 3	KM 4
パブリックPD	10万人以上	KM 2	KM 2	KM 4
	10万未満	KM 2	KM 3	KM 4
オペレーターの従業員のパブリックPD	どれでも	KM 2	KM 3	KM 4

個人データの保護レベルが高いほど、個人データのセキュリティに対する脅威を中和するために、個人データのセキュリティを確保するためのより多くの手段が必要になります。 誤ってより高いレベルのセキュリティを決定した場合、それに応じて、より高価なPD保護システムを構築する必要があります。 より低いレベルの保護を定義すると、法律の要件に違反することになります。

さらに、多くの保護対策が必要です。 ここでは、たとえば、特定のクライアント向けの調整なしの「すぐに使える」クラウドの対応表：

セグメントパラメータ	保護された	閉店
仮想化環境	OpenStack-KVM、VMware	VMware
予定	情報セキュリティのための特別な要件を持たない情報システムの配置。 銀行カード所有者のデータ処理に関係するものを含む、企業および組織の情報システムの配置	情報セキュリティの要件が最も高い状態情報システム（GIS）および個人データ情報システム（ISPDn）の配置
情報セキュリティに関するロシア連邦の法律の遵守	●ロシアNo. 21のFSTECの命令 ●ペイメントカード業界のデータセキュリティ標準（PCI DSS）-ペイメントカード業界のデータセキュリティ標準。 ●ロシア銀行規則No. 382-p「送金時の情報保護を確保するための要件と、送金時の情報保護を確保するための要件の遵守を監視するためのロシア銀行の手順について」 ●ロシア銀行標準（STO BR IBBS）	●ロシアFSTEC No. 17の命令 ●ロシアNo. 21のFSTECの命令 ●ロシア連邦法149-FZ ●ロシア連邦法152-FZ ●ロシア連邦法第242-FZ法
認証/認証	Payment Service Industry Data Security Standard（PCI DSS）の要件に対する適合証明書（サービスプロバイダーとして）	「クローズ」セグメントのインフラストラクチャが、情報システムおよび個人データをクラス1 /セキュリティレベルまで処理するシステムを配置するための情報セキュリティの要件に準拠していることの証明書
情報セキュリティ	保護装置を適用すると、次の要件を満たすことができます。 ●3番目のセキュリティレベルまでの個人データ情報システム。 ●PCI DSS標準。 ●ロシア銀行規則382-Pの規制	適用される保護装置により、次の要件を満たすことができます。 ●1番目のセキュリティクラスまでの情報システム。 ●第1セキュリティレベルまでの個人データ情報システム。 情報セキュリティを確保するために使用されるハードウェアおよびソフトウェアは、ロシアのFSTECおよび/またはロシアのFSBによって認証されています
物理的セキュリティ	ITインフラストラクチャの物理的セキュリティの確保： ●データセンターへのアクセスの制御と管理。 ●火災警報器。 ●自動消火活動; ●ビデオ監視。 ●安全なラック	ITインフラストラクチャの物理的セキュリティの確保： ●データセンターへのアクセスの制御と管理。 ●火災警報器。 ●自動消火活動; ●ビデオ監視。 ●安全なラック
ネットワークアクセス	●パブリックインターネット。 ●パブリックインターネットを介した安全なVPN接続（IPSec VPN-ソフトウェアプラットフォーム仮想化により実装）。 ●VPNチャネル	●ハードウェア暗号化保護で保護された別の通信チャネルを介して。 ●パブリックインターネット経由の安全なVPN接続（GOSTに準拠した暗号化保護を備えたIPSec VPN

クラウドの情報セキュリティは、境界の保護、外部のクリーニングセンターを使用したDDoSからの保護、または必要な機能を備えたプロバイダーへの接続から始まり、アクセスの提供と整理から成り、ネットワークの分離で終わります。

今、あなたが非政府の医療組織であるなら、すべてがもっと面白いです。 まず、個人データを処理しているかどうかを把握する必要があります。 簡単な式は次のとおりです。

{F. I.O. +生年月日+居住地} =個人データ
{F. I.O.}または{生年月日}または{居住地}≠個人データ

より多くの要因と組み合わせがあるため、最初に評価を行う必要があります。 次に、個人データを保護するために認証が必要かどうかを決定する必要があります。 非営利の営利会社の場合、これはオプションであり、オペレーターの要求に応じて実行されます。 しかし同時に、FSTECは、FZ-152によれば、個人データを保護する手段の有効性を定期的に評価する必要があることを想起します。 認証はそのような評価と見なされます。 つまり、それを行うことはできませんが、別の評価手順を実行する必要があるため、多くの人々がすぐに確実にそれを通過します。 別の理由-誤って、要件を理解していない。 3番目の理由-自己管理のため、標準に従って保護が実際に行われることを確認するために-連邦法-152では、一般的に非常に一般的なことが規定されています。 ここでは、最高のセキュリティクラスを持つシステムを保護し、そのためのインフラストラクチャを持っている方法を知っているという理由だけで、人々が私たちに来ることがあります。

移動する前に何をしますか？

クラウドインフラストラクチャに移行する前に、テストの問題に特別な注意を払う必要があります。 この段階で、顧客はクラウド自体と関連サービスがどのように機能するかについての真のアイデアを持つべきです。

テストには機能的でストレスの多い作業が必要です。 機能テストの結果、顧客はすべてが期待どおりに機能することを確認する必要があります。 ストレステストの結果、顧客はこれがすべて落ちないことを確認する必要があります。

テスト用のインフラストラクチャの初期評価では、戦闘の1/10を使用することをお勧めします。 たとえば、数百台ではなく10台の仮想マシンを使用してテストする必要があります。 テストシナリオは常にお客様と話し合います。

ヒットしたらどうなりますか？ リストを確認するには？

原則として、顧客がRoskomnadzorリストに載っている場合、予定外の検査が通知されるか、詳細なテストの時間がありません。 チェックのタイプは次のとおりです。

• Roskomnadzorは、事前に予定された検査について警告します。 原則として、今後のイベントに関する注文のコピーを含む通知は、少なくとも3営業日前に郵便またはFAXで送信されます。 Roskomnadzorの公式Webサイトで、法人（支店、駐在員事務所、個別の構造部門）および個々の起業家の計画的な検査について調べることができます。
• 予定外の検査は、ほとんどの場合、個人から受け取った苦情に対して実行されます。 Roskomnadzorは、24時間以内の予定外の検査について警告します。
• ドキュメンタリーチェック。 Roskomnadzorが文書のリストを要求するチェックのタイプ。そのコピーはRoskomnadzorの領土当局に提出する必要があります。
• フィールドチェック。 オンサイト検査では、ILVの代表者（通常は数人）が組織に来たときにオンサイト検査が実行されます。 FZ-152の要件に準拠しているかどうかのチェックがあります。

特に2番目のケースでは、問題を解決するために30日から1日まで残ります。 この時点で、顧客は私たちに目を向け、助けを求めます。 迅速な作業を実行するだけでなく、チェック中にすべてが正常であることを実際に確認するのに十分な時間がある場合があります。 手順を確認する準備が整いました。また、すべてが正常であるという事実も確認できます。 検査中にお客様をサポ​​ートします。

プラットフォームはすでに認証されているため、これにより、情報保護に関する法律の要件に準拠するために必要な労力が大幅に削減されます。 クラウドでは、必要なすべての境界セキュリティツール（ファイアウォール、侵入および攻撃の検出および防止ツール、暗号ゲートウェイ）および仮想化環境保護ツールを使用しています。 したがって、チェック中、クライアントは、情報保護機能の大部分がTechnoservによって実行されていることを示すことができ、これを確認するために必要なすべてを提供する準備ができています。

このような状況では、個人データと支払いデータにアクセスできないため、クライアントは独自に認証に合格する必要があります。 しかし、プラットフォームからすべてのドキュメントを提供し、情報システムの認証用のドキュメントセットを迅速に開発するのにも役立ちます。したがって、これは比較的簡単に初めて行われます。 クラウドセグメントは、政府システムを含むレベル1までの情報システムで認定されています。 インフラストラクチャはパブリッククラウドから分離されています。実際、仮想プライベートクラウドが取得されます。 すべての保護装置は、FSTECおよびFSBによって認定されています。

つまり、すでに行った作業の80％です。

アウトソーシングとして情報セキュリティ能力を提供します。 あなたは自分でそれを行うことができますが、実装の幅広い経験により、私たちは非常に短い時間を提供することができます。

建築

クラウドインフラストラクチャアーキテクチャの例を2つ示します。 組織が独自のDDoS保護コンプレックスを持っているのか、プラットフォームで提供されているDDoS保護コンプレックスが使用されているのかによって異なります。 ほぼ同じ方法で、他のコンポーネントや情報セキュリティを保護する手段にアプローチできます。

急いで仕事のタイムライン

1. 顧客システムを調べ、インフラストラクチャ要件とセキュリティ対策を決定します-2週間。
2. 移転計画と技術文書-2〜3週間。
3. 新しい組織および管理文書-2週間。
4. システムの移行-最大3週間。
5. 認証および認証に関する文書-さらに2〜3週間。

実用的な質問がある場合は、こちらに詳細と連絡先のページがあります ：security@ts-cloud.ru