web-dev-qa-db-ja.com

私の学校では、ドア認証システムの詳細を秘密にしたいと考えています。それは良い考えですか?

それで、私は私たちの学校のためにドア認証システムを設計しています(本当に詳細には入りません)。認証された人だけが特定の内部ドアを通過できるようにします。彼らは、その内部の動作は秘密にしておくべきであり、誰もそれをリバースエンジニアリングできないようにすべきであると考えています。これは obcursityによるセキュリティ であると主張しますが、これは悪いことです。 Kerckhoffの原理 のように、私はシステムがどのように機能するかを知っていても入らないようにするために設計しました。彼らはまだそれについて知っているより多くの人々の代わりに、より少ないべきであると主張しています。

閉じたデザインで行くのは良い考えですか?そうでない場合、正確にはなぜですか?

追伸彼らが私にそれの大部分を設計して、それが違いを生むなら、たくさんの人々に言った後、彼らはそれが秘密だと私に言っただけです(私が彼らがそれを秘密にしたいと思ったとは思いませんでした)。
P.P.S。外に開かれていませんが、保護している部屋には、学校の他の部分よりも貴重なものが含まれているため、オープンなデザインではなく、クローズドなデザインを採用すれば、敵はそれをリバースエンジニアリングできると思います。 、しかし、それをどのように伝えるかはわかりません。

108
PyRulez

あいまいさは、適切なセキュリティ対策ではありません。 あなたの唯一の、または最も重要なセキュリティ対策として、不明瞭に頼ることは、多かれ少なかれ基本的な罪です。

Kerckhoffの原理 は、多分、あいまいな方法でセキュリティを実装することに対して最もよく引用される議論です。ただし、システムがその原則に従ってすでに適切に安全である場合、これは誤った方向に導かれます。

言い換えると、この原則は「敵がセキュリティシステムの設計についてすべてを知っていると想定する」と述べています。これは、「敵がとにかく知っているので、システムについてすべてを敵に伝える」ことを意味するものでは決してありません。

システムがすでにケルクホフの原理に従って適切に設計されている場合、あいまいさを介してセキュリティを適用することについて言えることは、価値がほとんどない、またはまったくないことです。同時に、そのようなシステムの場合、その設計の機密性を保護しても害はほとんどありません。

242
Iszi

デザインの秘密を守ることは、ドアを危険にさらすことにはなりませんそれ自体;しかし、それがセキュリティを高めると信じることは危険な妄想です。

認証システムの詳細を明らかにすることでそれを破ることができる場合、そのシステムは純粋なジャンクであり、破棄する必要があります。したがって、あなたがあなたの仕事を適切に行ったなら、詳細を明らかにすることは無害であるべきです。あなたがした場合not仕事を適切に行い、自分を解雇し、有能な人を雇います。

すべての一般論として、システムの詳細を公開すると外部レビューが促進され、その結果、不具合修正サイクルが発生し、最終的にセキュリティが向上します。学校のコンテキストでは、システムの詳細を公開しないとセキュリティが損なわれます。学校は学生でいっぱいであり、学生は、彼らから秘密にされているもののリバースエンジニアリングに特に魅了される、うるさいアナキストであることが知られています。学生のコンピュータールームでセキュリティインシデントを低く抑える最善の方法は、root /管理者のパスワードを数人の学生に与えることです-学生がコンピューターのセキュリティに手を出してフルアクセスを許可したい場合物事を壊そうとするすべてのインセンティブを取り除き、彼を他の学生を監視するための無料の警察補助員に変えます。

また、セキュリティシステムの内部の仕組みを詳しく説明することは、教育学的に非常に困難な場合があります。一部の学校では、少なくとも時折、実際に教育学を実践していると聞きました。あなたの学校はそれを試してみたいかもしれません。

103
Tom Leek

@TomLeekの回答と@Isziの回答(どちらもすばらしい)は直接矛盾しているようですが、すでにいくつかの優れた回答を受け取っています。

どちらも優れた点を示します。一方で、設計の秘密を守ることはシステムを安全にすることはできませんが、それを公にレビューすることで、(おそらく)考慮しなかった特定の脆弱性を見つけることができます。一方、デザインの秘密を守ることは、実際には害になりませんそれが重要な要素でない限りデザインのセキュリティ。

両側が完全に正しい-ときどき

一般論の両サイドで、設計を秘密にしておくとセキュリティが直接向上しないことに同意するだろうと言っても差し支えないと思います。
最悪の場合、それは単にhidesセキュリティの弱点です(誰から最も隠されていると考えるかによって、これは良いことかもしれないし、そうでないかもしれません)。
最良の場合(デザインを公開することで明らかになる脆弱性がない場合)でも、セキュリティは向上しませんが、does最小限に抑えられますattack表面

(脆弱性が存在しなくても)攻撃対象領域を最小限に抑えることは、間違いなく良いことです。ただし、これは、パブリッシングの利点(つまり、追加の目でレビューされている)と、それを秘密にしておくことのマイナス面(たとえば、セキュリティシアターの一種として、セキュリティコントロール(あいまいさによるこれまで人気のあるセキュリティ)としてこれに依存する誘惑。

@Tikimanが言及したように、デザインを公開するだけではそれが確実であることを保証するのに十分ではないことも注目に値しますreviewed-特に脆弱性を見つけることができ、また開示する傾向がある人によるそれらをあなたに。多くの場合、公開された設計は、不法な意図を持つ悪意のある個人によってのみレビューされるため、期待した利益を得ることができません。さらに、設計が前述のベストケースまたはワーストケースに該当する場合は、多くの場合わからないです。

つまり、結論としては、セキュリティに関する多くのことと同様に、正解は次のとおりです依存する

ここで考慮すべき明確なトレードオフがあります-これが複雑な暗号システムである場合、答えは明白です。これが実装を多用する典型的なエンタープライズシステムである場合、別の答えが明らかになります。

私の学習この場合は@Tomが言ったとおりですが、言及された副次的な理由のために-一部は無政府のユーザーベースであり、ほとんどが教育的目標です。

これらは実際には実際にはセキュリティの考慮事項ではないことに注意してください-少なくとも直接には考慮されません。

(ああ、@ Tikimanのポイントに関しては-ここに含まれる教育学は、少なくともクラス全体でデザインが実際にレビューされていることを確認できることを意味します;-))

29
AviD

これはダニエル・ミスラーの 記事 です!

それはそれを述べています

あいまいさによるセキュリティは悪いですが、他のコントロールの上にレイヤーとして追加された場合、あいまいさは完全に正当です。

そのコンセプトを持つことで、はるかに良い質問は

私が持っているコントロールが与えられた場合、リソースを最大限に活用するには、あいまいさを追加するのでしょうか、それとも、別の(非あいまい度ベースではない)コントロールを追加したほうがよいでしょうか。

camouflageのアノロジーをobscurity as another layer of securityとして使用することもできます

これの強力な例はcamouflageです。 M-1のような装甲戦車を考えてみましょう。 戦車には、これまでに使用された最も進んだ鎧がいくつか装備されており、実際の戦闘で効果的であることが繰り返し示されています。

したがって、この非常に効果的な鎧を与えられた場合、タンクが周囲と同じ色で塗装されると、タンクへの危険性はどういうわけか増加しますか?またはどうですか将来、タンクを完全に見えなくすることができますか?装甲の有効性を低下させましたか?いいえ、しませんでした。 何かを見づらくしても、発見された場合、または発見されたときに攻撃しやすくなるわけではありません。これは、単に終わらせなければならない誤りです。

成功した攻撃の数を減らすことを目標とする場合は、テスト済みのしっかりとしたセキュリティから始めて、レイヤーとしてあいまいさを追加することで、セキュリティ体制に全体的なメリットがもたらされます。迷彩は戦場でこれを達成し、PK/SPAは強化されたサービスを保護するときにこれを達成します。

鉱山を強調します。

Isziのコメントも素晴らしいです。彼は、Wordをaddingからenforcingなので、要約すると次のようになります。

概要:

あいまいさによるセキュリティは悪いですが、他のコントロールの上にあるレイヤーとしてあいまいさで実施されるセキュリティは、完全に正当である可能性があります。 戦車が環境と同じ色で塗装されていると思うので、戦場で安全であると仮定すると、単純なナンセンスです。しかし、戦車の防御力を高め、ペイントを適用することで、カモフラージュ能力を別の保護層として付与できます。

14
Cary Bondoc

あなたの質問には実際には答えませんが、これはあなたの学校への議論として役立つかもしれません。

私は誰かが承認されたキー/アイデンティティにアクセスすることを本当のリスクと考えます。人々はだらしがなく、不正なパスワードを使用し、常に秘密を書き留めます。私の学校の先生は、昔、学生のトイレに鍵を学校全体に置いていました。

その部屋に入ろうと思ったとしても、ソフトウェアのセキュリティホールを見つけようとすることさえありません。キーを盗んだり、物理的なロックを改ざんしたり、その他の外部的な方法を試したりします。

または、データを破壊するために学校のシステムをハッキングする方法を校長から尋ねられたとき、私の友人が言ったように; 「私は野球のバットを使います」。

8
axl

私はさまようように見えるかもしれない長い説明を持っているので、私は短く答えて、それを正当化します。簡単に言えば、これはあいまいさによるセキュリティですが、システムに接触する人の数が多いため、これはおそらく問題ではありません。ですから、議論する価値はないでしょう。

あなたは、システム設計を秘密に保つことが不明瞭さ(STO)によるセキュリティであるというあなたの主張は正しいです。 STOが悪い考えである主な理由は、内部の仕組みが最初に知られていないシステムは、注意深く観察し、ソーシャルエンジニアリングを適切に適用することによって、すべてのケースでリバースエンジニアリングできるためです。システムがどのように機能するかを理解しているのがあなただけの場合、その完全性を検証できるのはあなただけです。したがって、設計にバイパス可能な潜在的な欠陥があり、誰かが設計をリバースエンジニアリングして発見した場合、設計を秘密にしておかなかった場合よりも簡単に悪用することができます。彼らはまた、発見を守り、違法な使用を秘密にできる可能性が高くなります。

これは、デザインを一般に公開すると、より多くの人々がそれを検討するようになるため、より多くの人がデザインを検討するほど、誰かが既存の欠陥を発見してそれを伝える可能性が高くなるためです。設計上の欠陥は、一般的な概念にさえあるのではなく、他の点では安全なアルゴリズムの実装におけるバッファオーバーフローの機会など、特定の実装にある可能性があります。公開暗号プリミティブの使用の主な概念は、暗号プリミティブアルゴリズムを誰もが認識できるようにすることで、他の人がそれをレビューできるようにすることです。多数の個人が行った後は、設計が安全であることを合理的に保証できます。難しさは、学校のデザインを作成しているため、デザインを表示する可能性があるのはごく少数の人だけであり、デザインを理解する可能性があるのはごく少数の場合です。あなたのデザインを見る人が少ないほど、欠陥を発見した誰もがその欠陥を報告しない可能性が高くなります。

設計をレビューしてくれるセキュリティ専門家の大規模なコミュニティにアクセスできない場合を除いて、彼らに彼らのやり方を任せることは、実際のセキュリティに関してはほぼ同じかもしれません。

3
Tikiman163

私がドアの責任を負っていれば、機密保持についても同じ要件があります。もし世界(そしてあなたの仕事)が完璧だったら、あいまいさは実際には役に立たないでしょう。

しかし、実際に実際に起こっていることを考えてみてください。最先端のアルゴリズムを使用して、できる限りの仕事をしたと思います。しかし、悪魔は詳細を隠し、実装の詳細canはセキュリティを弱めます。アルゴが本当に安全であったとしても、それはずっと昔にSSLライブラリに起こりました。

セキュリティシステムの詳細を開示するときに必要なのは、ピアが実装を確認し、攻撃者が発見して使用する前に欠陥を警告することです。あなたがセキュリティシステムの専門家を知っていて、彼らにあなたの仕事をレビューしてもらうなら、私はそれがあなたの学校でも良い実践と見なされると思います-私見それすべき少なくとも。しかし、あなたがそれを公開するだけなら、あなたの最初の読者がドアのセキュリティが構築された対象になる可能性が高くなります!そして、あなたは間違いなく、彼らがあなたの仕事を考えられる欠陥について最初にレビューすることを望まないでしょう。

TL/DR:大規模なオーディエンスを抱える可能性のある一般的なセキュリティシステムを構築し、本番環境ですぐに使用しない場合は、良いレビューを得るためにできるだけ広く公開する必要があります。ただし、実際のセキュリティにすぐに使用される専用の実装を構築する場合は、信頼できる専門家にのみ詳細を開示して、攻撃者が欠陥を見つける手助けをしないようにします。

0
Serge Ballesta

明らかな目標の1つは、ドア認証システムが学生によってハッキングされないことです。

認証システムがハッキングするのはわずかではあるがそれほど難しくないと想定し、高度なハッキングスキルはあるが高度ではない学生がいる場合、システムの詳細を使用不可にすることによって生じる追加の困難で十分である可能性があります。そのグループ(学生)の手の届かないところに置くため。

一方、システムのセキュリティが非常に高くなり、クラッキングがシステムの動作を見つけたりリバースエンジニアリングするよりもはるかに困難になると、詳細を秘密にしておくことはあまり役に立ちません。

0
gnasher729