社内で使用されているドメイン名のセットがあり、それを外部に漏らしたくありません（漏洩すると、攻撃者に内部ネットワークのレイアウトに関する高度な情報を与えることになるため）。証明書の透明性勢いを増しているようですが、プライベート ドメイン名を取得する最善の方法についての一般的なコンセンサスは何ですか? 自己署名証明書ですか? ワイルド カード証明書ですか? それとも他の方法ですか?
答え1
社内で使用されているドメイン名のセットがあります
内部のみで使用する場合は、プライベート CA を設定し、その証明書を内部システムにインストールして、内部証明書を自分で発行することができます。
もしあなたの内部使用サーバーが何らかの形で外部から使用されている場合、外部クライアントが証明書の例外を追加しない限り、サーバーは機能しません。これにより、外部の攻撃者が内部ドメインを発見して攻撃するのを防ぐことはできません。この場合は、ワイルドカード証明書を使用します。自己署名証明書または内部 CA 証明書を使用すると、外部ユーザーに迷惑をかけるだけでなく、攻撃者から保護する効果もありません (ほとんどの DRM スキーマと同様)。
答え2
ホスト名の漏洩が脅威モデルの一部である場合、CT はおそらくそのような漏洩の唯一の原因ではありません。電子メール ヘッダー、ログ、監視、コンパイラなど、多くのツールが最終的にシステム名 (ホスト名または証明書の一部) をパブリックにアクセス可能なスペースに漏洩する可能性があります。むしろ、それらを機密にしておくことを望む根本的な理由に取り組んでください。
秘密でなければ、隠す必要はありません。もし名前が何らかの情報を漏らす場合は、通常、名前を
- 管理者が自分のネットワークをナビゲートするのを手伝ったり、
- 同僚が入力する URL を思い出せるようにします。
- 商用運用前に社内でシステムをテストする
これら 3 つの問題には、よりよい解決策があります。1. の主な問題は、システム名が何度か変更されると、システムの役割と一致しなくなることがほとんどです。2. の主な問題は、同僚が URL を手動で入力するべきではないことです。スペルミスのドメイン詐欺を考えてみてください。コード名は 3. を解決します。
推奨事項: 内部サーバーに、一貫性がありながらもランダムな名前を付けます。システム <> ロールの関係は、まったく異なる方法で伝えます。通常、同僚をロールではなく名前で呼びますが、内部サーバーでも同様です。
弊社の内部 wiki は でホストされていますlake.example.org。Lake は特に意味はなく、cube.example.org(ログ コレクション) とは十分に異なるだけです。しかし、悪意のある攻撃者は、内部ドメインが 8 つあることしか知りません。これは、組織の規模を考えると驚くことではありません。詳細を知りたい場合は、弊社を訪問して名札を読む必要があります。
答え3
何か見落としていない限り、これはかなり簡単な決定のように思えます。
証明書の透明性によって公開されるデータのプライバシーが、公的に信頼された CA によって署名された証明書を持つことの利便性よりも重要であると判断した場合は、次のいずれかを実行します。
- 証明書を使用しないでください（賢明ではなく、最新のソフトウェアでは実行不可能です）
または
- 独自の CA を実行し、クライアントがそれを信頼するように設定する際の不便さに対処します。