クラシックMERNスタック(MongoDB、Express、React、Node)で構築されたWebアプリケーションがあり、管理ルートを作成したいので、[url]/admin
ルート。
これはセキュリティ上のリスクでしょうか?もちろん、管理者ユーザーは何らかの認証を求められますが、管理者パネルをパブリックルートとして使用することは悪い習慣ですか?
既知の管理URLを使用することはセキュリティ上の欠陥ではありません。秘密にする必要があるのは、URLではなく管理資格情報です。それはドアを隠すようなものですが、実際には安全を確保するための鍵です。
人間の警備員、周辺フェンス、非常に安全なロック、頑丈な壁などを使用して、ドアをよりよく保護できます。これにより、誤った安心感を与えることはありません。ロックは、許可された人だけが入ることができるように安全でなければなりませんが、これらの対策助けられる。
それらをデジタルの世界に変換すると、管理パネルをIPアドレスのホワイトリスト(IDカードをチェックするガード)の背後に置くことができ、多要素認証(追加の安全なロック)が可能で、内部管理ネットワークインターフェイス(フェンス)を介した接続のみを許可できます、など.
わずかには、既知/予測可能なURLを持たないようにするのに役立ちますが、これは主に一般的なアプリケーションで役立ちます。 1万WordPress= Webサイトがそこにあり、セキュリティの問題が見つかった場合、ハッキンググループが最初に行うことは、可能な限り多くの/wp-admin
ページにハッキング試行を送信することです(標準WordPress管理URL)。URLを/wp-admin5839
に変更した場合、ターゲットを絞った攻撃でサイトが最初の波に当たることはありません。 、オッズは管理ページを推測するのに時間を費やしている、またはなんらかの方法でそれを理解するのに時間を費やしていること、そしてセキュリティの問題が判明したら、パッチを適用する前に非表示のページでそれを使用するだけです。あまり役に立ちませんが、特定のシナリオでは少し役立ちます。
それはあなたのアプリケーションのユースケースに依存します。組織内にある場合は、特定のソースIPからのリクエストにのみ応答するように管理パネルを制限できます。証明書ベースの認証を使用することもできます。これは、従来のパスワードベースの認証よりも安全です。
Wordpressなどの「一般的な」ソフトウェアを作成する場合は、個人から大規模な組織まで、大多数の顧客がそのソフトウェアを使用できることを確認する必要があります。したがって、顧客のインフラストラクチャについての仮定を立てることは困難です。
一般に、それ自体は本当に脆弱性ではありませんが、必要でない限り、それを公開することは不必要なリスクです。
管理ページへのルートを変更すると、自動化されたボットやスクリプトキディに対する防御策が提供される可能性があります。 「/ mysupercustomapp-admin /」(ディレクトリワードリスト内)。私にとっては、SSHポートをデフォルトの22から変更するという概念に似ているため、自動スキャンや無作為なブルートフォース試行で見逃されます。
しかし、それを超えて、隠された管理ページを本当に保護に頼っているのなら、それはほとんど「あいまいさによるセキュリティ」だと言えるでしょう。 URIパスが非常に長く、入力するのが難しい(使い勝手が悪い)場合を除き、断固とした攻撃者は自動または手動の手段でそれを見つけることができます。
代わりに、一般的に認証の保護に焦点を当てる必要があります。適切なパスワードの強度を適用し、キャプチャやレート制限の認証試行を検討し、おそらくクライアント証明書を要求し(適切な場合)、2FAを実装し、管理ページへのアクセスを信頼できる/内部IPアドレスのみに制限し、アカウントのロックアウトまたは一時的な禁止を検討します(許可DoSの場合はトレードオフ)。
TL; DR:多層防御ソリューションの一部である場合、非標準の管理ページパスに利点があるかもしれませんが、決してそれに頼るべきではありません。
一般向けのアプリに管理ルートを配置しないでください。ハッカーが管理URLにアクセスしようとしたログの量は信じられないほどです。
最善のオプションは、管理者を2番目のアプリのあいまいなURLと別のハードウェアに置くことです。 SSL/TLSで管理アプリを保護し、認証に2FAまたはSSL証明書を使用and暗号化。
これには、アプリ(マイクロサービス)を簡素化し、復元力を高めるという追加の利点があります。