FSTECの新しい注文に従って個人データを保護します。 他に回答や質問がありますか?

2013年5月15日、法務省は2013年2月18日のFSTEC No. 21の命令を最終的に登録しました。「個人データ情報システムでの処理中の個人データのセキュリティを確保するための組織的および技術的措置の構成と内容の承認について」



なぜ「待望の」のですか? はい。RF政府令1119(2012年11月1日)が発表された瞬間から、個人データの技術的保護に関する質問は不確実な状態にありました。 新しい解決策により、古いクラスの個人データ情報システム(ISPDn)が廃止され、「ISPDnセキュリティレベル」の概念が導入されましたが、特定のケースでどのように、また何を守るべきかそれから6ヶ月。



新しい注文がインターネットに公開された直後、熱狂的なレビューの波が新しい文書を席巻しました。 同様に、これは個人データ保護法の分野での大きな前進です。 ある程度、これは確かにそうです(以前のドキュメントがすぐに時代遅れになり、モバイルプラットフォーム、仮想化など、現代の情報システムの機能のニュアンスの多くを考慮していなかったため)。しかし、個人的に、私は新しいドキュメントについて多くの不満を持っています。



この記事では、ロシアの新しいFSTEC文書を簡単な言語で分析し、その長所と短所を比較検討し、「個人データオペレーターは今何をしていますか?」という質問に答えようとします。







文書全体とは何ですか





一般的に、これは個人データ保護の分野での立法の観点から実際に一歩前進です。 最後に、対策のリストで、以前の議員が慎重に回避しようとしたモバイルデバイスと仮想化ツールについて言及しました。 最後に、前の順序のような義務はありません。「クラス1のISPDがある場合、情報保護手段にnお金を費やす必要があります。2クラスである場合はnm money、3クラスである場合はnmk money。」



現在の状況は次のとおりです。さまざまな技術的および組織的対策の15のグループがあり、各グループに2から20の異なる対策があり、各対策の反対側に、この対策が特定のレベルのセキュリティに対して基本的であるかどうか(以下では条件付き必須と呼びます)プラス、そうでない場合、メジャーは基本的です-補償)。 ここでは、リストに多くの対策しかありませんが、それらは補償できるだけであることに注意してください。つまり、4つのセキュリティレベルのいずれにもプラスのマークは付いていません。



個人データオペレーターは、次のアルゴリズムに従って動作します。

-PP 1119に従ってISPDnのセキュリティレベルを決定します。

-選択したセキュリティレベルにプラス記号が付いているすべての対策(基本対策)を選択します。

-ISPDnで使用されていないテクノロジに関連付けられている対策をリストから削除します(たとえば、仮想化ツールが使用されていない場合に仮想インフラストラクチャを保護する対策を削除します)。

-受信した対策のリストを見て、脅威モデルの実際の脅威と比較します。すべての実際の脅威が選択した対策で中和されない場合、残りのすべての脅威を中和するために必要な補償対策をリストに追加します。

-他の規範的行為で定義されている対策をリストに追加します(たとえば、PP No. 1119には、FZ-152の一般的な要件と同様に、少数の対策があります)。その後、実行する必要のある対策の最終リストを受け取ります。

-最終リストから対策を実行します...



すべてが単純に思えます。セキュリティレベルを決定し、脅威のモデルを作成し、FSTECの新しい注文から対策を選択および改良し、これらの対策を実行します。 しかし...



軟膏で飛ぶ





実際、新しい文書とその他の法律全体に対する批判はここから始まります。



FSTEC全体の21の命令の問題は、他の多くの立法文書の問題と同じです-あいまいな文言の使用、テキストの二重解釈の可能性、それらが重要な場合の説明の欠如。



文書の作成がどれだけ徹底して行われ、過去6か月間に何度も再読および編集されたことが、順序の4番目の段落の直後に6番目になったという事実によって理解できます...さて、これはちょっとピッキングですが、ポイントは何ですか?



誤解は、太古の昔から続くこのジャンルの古典から始まります。 この文書の第2項では、機密情報の技術的保護(TZKI)のライセンスを持つ組織がPDを保護するための作業に関与する可能性があると述べています。

このフレーズは、ドキュメントからFSTECドキュメントへと長い間さまよっていましたが、「かもしれない」という意味は明確な答えではありません。 当然、cなインテグレーターは、これを「TZKIのライセンスを持っていないサードパーティ組織を引き付けることができる」と解釈します。 正式には、彼らは正しいでしょう。なぜなら、あなたが他の規範的な行為を掘り下げると、ウイルス対策の些細なインストールでさえTZKIに該当することがわかり、TZKIに関するライセンス条項には、仕事が個人的なニーズのために実行される場合、ライセンスは不要であることが判明しているためです。 しかし、事業者はお金を捨てるのが好きではなく、残念ながらcなインテグレーターの常識を取り入れ、この提案を「彼らは引き付けることができるが、自分でできる」と解釈します。 これは、サードパーティ組織を誘致するための条件をより具体的に説明しても害にならない最初の場所です。



さらに進んでいます。 パラグラフ3は、セキュリティ対策は現在のセキュリティ脅威を中和することを目的とすべきだと述べています。 一方、FZ-152は、個人データ保護の要件満たすために組織的および技術的な手段が適用されることを示しています 。 それでも、私たちには自由や別の義務がありますか? 再度説明が必要です。



次。 第6段落では、3年に1度、オペレーターは単独で、またはサードパーティ組織の関与を得て、実装されたPD保護対策の有効性を評価する必要があると述べています。 152-FZの個人データの主題への危害の評価方法が判明しました。 評価を実施する必要があることが判明しましたが、そのような評価を実施するための方法論はありません。 または、有効性の評価は、情報システムの認証の代わりになるのでしょうか? それでは、なぜオペレーターはTZKIのライセンスなしでそれを独立して実施できるのでしょうか?



一見したところ、文書の第10段落は非常に有望であり、「 個人データのセキュリティを確保するために特定の選択された対策を技術的に実施することが不可能であり、経済的実行可能性を考慮して、対策の基本セットの適応および(または)適応された基本セットの洗練の段階で他の段階が開発される可能性がある場合、 「(補償)個人データのセキュリティに対する現在の脅威を中和することを目的とした対策 。」



ここにあるように思えます-私たちは経済的な不便さを参照し、認定された救済策を購入しません。 さて、次の段落は幸福感から私たちを導きます: 「この場合、個人データ保護システムの開発中に、個人データのセキュリティを確保するための補償措置の適用の正当化が実行されるべきです。



それは、検査官に「みんなと私はそれを理解し、認定SZIを実装し、無料の中国のウイルス対策ソフトをインストールするには費用が高すぎると判断した」と伝える方法です。 基本的なものではなく、他の手段の使用を正当化するいくつかの紙片を示す必要があります。 正当化する方法は? これまでのところ、ISO 27001に従ってリスク分析手順を実行することしか考えていません。第三者機関がこれらの目的のために雇われた場合、それ自体でかなりの費用がかかる可能性があります。 さらに、リスク分析により、認定されたSISを実装することは経済的に実行可能ではないことが示されるという事実ではありません...



実際、ここではドキュメントの主要部分、つまりメジャーのリストを含む付録に進みました。 ここでも、私たちが望むほど単純ではありません。 メジャーはグループに分割され、便利な番号が付けられているようです。プラスの付いた便利な列は、この場合、このメジャーまたはそのメジャーが条件付きで必須かどうかを示しているようです。 しかし、とにかく、メジャーでテーブルを調べた後、不確実性の感覚が残っています。 たとえば、注文のメインテキストのパラグラフ4は、認定されたSZIのみを適用するようになったようです。 これはいいです。 しかし、同じ段落では、非認証のSZIを使用することも、SZIをまったく使用しないことも可能であるとプレーンテキストで述べていません。 これが逐語的にどのように聞こえるかです:

個人データのセキュリティを確保するための対策は、とりわけ、個人データのセキュリティに対する現在の脅威を中和するためにそのようなツールの使用が必要な場合に、所定の方法適合性評価手順に合格した情報システムの情報保護ツールの使用を通じて実装されます。



同時に、すべてのセキュリティレベルで条件付きで必須となる最初の手段は、 「オペレーターの従業員であるユーザーの識別と認証」です。 この措置は、OSの通常の手段でも実装できることは明らかです。 また、4番目の段落では同じシークレットネットまたはダラスロックの使用を義務付けられていないようですが、審査官が来て「あなたはすべて誤解されています。認定SZIが必要です。ここに処方箋がありますか?」 特定の脅威を無力化するために、認定SISが必要であるか、それをなくすことができるかを誰が決定しますか 認定SISを使用する必要がない、または特定の場合に必要であるとプレーンテキストで記述できないのはなぜですか?



さて、対策自体の文言は時々非常に興味深いです。 たとえば、3番目以降のセキュリティレベルの仮想化環境の保護の条件付き必須手段:

「仮想インフラストラクチャをセグメントに分割して、個々のユーザーおよび/またはユーザーのグループが個人データを処理します。」



何かをセグメント化する原理は何ですか? そして、何が必要ですか? もちろん、一連のメジャーを調整または調整する場合、このメジャーをリストから削除できますが、再度、レビュアーが「あなたはすべて誤解した...」と言った場合は?



それでも、FSTECの代表者が、論争の的となっている問題について公式の説明をすることをいつか期待しています。



履歴書の代わりに





一般に、個人データ保護戦略を選択する際に事業者により大きな行動の自由を与えようとするFSTECの試みは注目に値しますが、言葉遣いの曖昧さとあいまいさは、物議を醸す問題における規制当局の地位のあいまいさと相まって、警戒を促します。



オペレーターは今何をすべきですか?



「古いスタイル」でISPDをすでに擁護している人は、現在の法律に合わせてドキュメントをわずかに修正してください。 いずれにせよ、以前の要件はより厳しかったので、ほとんどの場合、技術用語での保護システムは新しいドキュメントに対応します。



残りは、ISPDを分類し、脅威モデルを構築し、対策のリストをコンパイルし、可能な限りそれらを実装することです。 規制の明確化、監査慣行、専門家の意見、およびこの分野の法律の開発における一般的な傾向に関するあらゆる種類のニュースを監視します。



All Articles