Webサイトの管理セクションを保護するためのベストプラクティスは何ですか？[閉まっている]

特に認証/アクセスの観点から、ウェブサイトの管理セクションを保護するためのベストプラクティスを人々がどのように考えているかを知りたいのですが。

もちろん、SSLを使用したり、すべてのアクセスをログに記録したりするなど、明らかなことはありますが、これらの基本的な手順の上のどこに人々がバーが設定されていると考えているのでしょうか。

例えば：

• 通常のユーザーに使用するのと同じ認証メカニズムに依存していますか？そうでない場合、何ですか？
• 同じ「アプリケーションドメイン」で管理セクションを実行していますか？
• 管理セクションを未発見にするためにどのような手順を踏んでいますか？（または「あいまいな」こと全体を拒否しますか）

これまでのところ、回答者からの提案は次のとおりです。

• ブルートフォース攻撃を防ぐために、各管理者パスワードチェックに人工的なサーバー側の一時停止を導入します[開発者向けアート]
• ユーザーと管理者が同じDBテーブルを使用して別々のログインページを使用する（管理エリアへのアクセスを許可するXSRFとセッション盗用を停止するため）[Thief Master]
• Webサーバーのネイティブ認証を管理領域に追加することも検討してください（例：.htaccess経由） [Thief Master]
• 多数の管理者ログイン試行の失敗後にユーザーのIPをブロックすることを検討してください[Thief Master]
• 管理者のログイン試行が失敗した後にキャプチャを追加する[Thief Master]
• ユーザーと管理者に（上記の手法を使用して）同等に強力なメカニズムを提供します（たとえば、管理者を特別に扱いません）[Lo'oris]
• 2番目のレベルの認証を検討してください（クライアント証明書、スマートカード、カードスペースなど）[JoeGeeky]
• 信頼できるIP /ドメインからのアクセスのみを許可し、可能であれば、基本的なHTTPパイプラインに（たとえば、HttpModulesを介して）チェックを追加します。[ジョーギーキー]
• [ASP.NET] IPrincipalとPrincipalをロックダウンします（それらを不変で列挙できないようにします）[JoeGeeky]
• フェデレート権限の昇格-たとえば、管理者の権限がアップグレードされたときに他の管理者にメールを送信します。 [ジョーギーキー]
• 管理者にきめ細かい権限を検討します。たとえば、役割ベースの権限ではなく、管理者ごとに個別のアクションの権限を定義します[JoeGeeky]
• 管理者の作成を制限-たとえば、管理者は他の管理者アカウントを変更または作成できません。これには、ロックダウンされた「superadmin」クライアントを使用します。[ジョーギーキー]
• クライアント側のSSL証明書、またはRSAタイプのキーフォブ（電子トークン）を検討する[Daniel Papasian]
• 認証にCookieを使用する場合は、たとえばadminセクションを別のドメインに配置するなどして、adminページと通常のページに別々のcookieを使用します。[ダニエルパパシアス]
• 実用的な場合は、管理サイトをプライベートなサブネット上に置いて、パブリックインターネットから切り離すことを検討してください。[ジョンハートソック]
• Webサイトの管理/通常の使用コンテキスト間を移動するときに認証/セッションチケットを再発行する[Richard JP Le Guen]

これらはすべて良い答えです...私は通常、管理セクションにいくつかの追加レイヤーを追加したいです。私はテーマにいくつかのバリエーションを使用しましたが、通常は次のいずれかが含まれています。

• 2番目のレベルの認証：これには、クライアント証明書（例：x509証明書）、スマートカード、カードスペースなどが含まれます。
• ドメイン/ IP制限：この場合、信頼できる/検証可能なドメインからのクライアントのみ。内部サブネットなど。管理領域へのアクセスが許可されています。リモート管理者は、多くの場合、信頼できるVPNエントリポイントを通過するため、セッションは検証可能であり、RSAキーで保護されることもよくあります。ASP.NETを使用している場合は、HTTPモジュールを介してHTTPパイプラインでこれらのチェックを簡単に実行できます。これにより、セキュリティチェックが満たされていない場合にアプリケーションがリクエストを受信できなくなります。
• IPrincipal＆Principal-based Authorizationのロックダウン：カスタムプリンシパルを作成することは一般的な慣例ですが、よくある間違いはそれらを変更可能にしたり、権利を列挙可能にしたりすることです。これは単なる管理者の問題ではありませんが、ユーザーが高い権限を持っている可能性が高い場所なので、より重要です。それらが不変であり、列挙できないことを確認してください。さらに、承認のすべての評価がプリンシパルに基づいて行われることを確認してください。
• フェデレート権限の昇格：アカウントが選択した数の権限を受け取ると、すべての管理者とセキュリティ担当者にメールですぐに通知されます。これにより、攻撃者が権利を昇格した場合、すぐにそれを知ることができます。これらの権利は一般に、特権、プライバシーで保護された情報を見る権利、および/または金融情報（クレジットカードなど）を中心に展開します。
• 管理者であっても、権限を慎重に発行します。最後に、一部のショップではこれを少し高度にすることができます。承認権はできるだけ控えめにする必要があり、実際の機能動作を囲む必要があります。典型的なロールベースのセキュリティ（RBS）アプローチは、グループの考え方を持つ傾向があります。セキュリティの観点からは、これは最良のパターンではありません。「ユーザーマネージャー」のような「グループ」の代わりに、さらに細かく分解してみてください（例：ユーザーの作成、ユーザーの承認、アクセス権の昇格/取り消しなど...）。これにより、管理の面で少しオーバーヘッドが増える可能性がありますが、これにより、大きな管理者グループが実際に必要とする権限のみを割り当てる柔軟性が得られます。アクセスが危険にさらされた場合、少なくともすべての権利を取得できるとは限りません。これを.NETとJavaでサポートされているコードアクセスセキュリティ（CAS）アクセス許可でラップしたいのですが、それはこの回答の範囲を超えています。もう1つ... 1つのアプリでは、管理者は他の管理者アカウントの変更を管理したり、ユーザーを管理者にすることはできません。これは、ロックされたクライアントを介してのみ行うことができ、クライアントは数人しかアクセスできません。

フォーラムなど、通常のアクティビティと管理者の両方にログインが必要なWebサイトの場合、同じユーザーデータベースを使用する個別のログインを使用します。これにより、XSRFとセッション盗用によって、攻撃者が管理領域にアクセスすることはできなくなります。

さらに、adminセクションが別のサブディレクトリにある場合は、Webサーバーの認証（Apacheの.htaccessなど）でセキュリティ保護することをお勧めします。その場合、誰かがそのパスワードとユーザーパスワードの両方を必要とします。

管理パスを覆い隠しても、ほとんどセキュリティ上の利点はありません。誰かが有効なログインデータを知っている場合、フィッシングまたはキーログを記録したか、ソーシャルエンジニアリングを介して取得したため、管理ツールのパスを見つけることもできます（おそらく、パスも）。

ログインが3回失敗した後にユーザーのIPをブロックしたり、ログインが失敗した後にCAPTCHAを要求したりするようなブルー​​トフォース保護（最初のログインではなく正当なユーザーにとっては非常に煩わしいため）も役立つ場合があります。

• あいまいさを拒否する
• 1つではなく2つの認証システムを使用するのはやり過ぎです
• 試行間の人工的な休止は、ユーザーに対しても行う必要があります
• 失敗した試行のIPのブロックは、ユーザーに対しても行う必要があります
• ユーザーも強力なパスワードを使用する必要があります
• captchasが大丈夫だと思うなら、何を推測すれば、ユーザーにも使用できるでしょう。

はい、それを書いた後、私はこの答えが「管理者ログインに特別なものは何もない、それらはすべてのログインに使用する必要があるすべてのセキュリティ機能です」と要約できることに気づきました。

通常のユーザー特権と管理者特権の両方を持つユーザーに対して単一のログインのみを使用する場合は、レベルが変更されたときにセッション識別子（CookieまたはGETパラメータなど）を再生成します。特権...少なくとも。

そのため、ログインした場合、通常のユーザー操作を行ってから管理ページにアクセスし、セッションIDを再生成します。その後、管理ページから通常のユーザーページに移動した場合は、IDを再生成します。

適切な管理者パスワードを用意してください。

"123456"15文字から20文字など、十分に長い文字、数字、特殊文字のシーケンスではありません。のように"ksd83,'|4d#rrpp0%27&lq(go43$sd{3>"。

ブルートフォース攻撃を防ぐために、パスワードチェックごとに一時停止を追加します。

考慮すべきその他の事項を以下に示します。

1. 特に管理者のコンピューターを管理している場合、または技術的に優れている場合は、SSL認証に基づいたものをクライアント認証に使用することを検討してください。RSAキーフォブやwhatnotを使用して、セキュリティを強化することもできます。
2. おそらく認証/セッショントークンのためにCookieを使用している場合、おそらくCookieが管理ページにのみ送信されるようにする必要があります。これにより、レイヤー1/2の侵害またはXSSによってCookieを盗むことで、サイトにもたらされるリスクを軽減できます。これは、adminの部分を別のホスト名またはドメインに配置し、Cookieでセキュアフラグを設定することで簡単に実行できます。
3. IPによる制限もスマートになり、ユーザーが参加できる信頼できるVPNがあれば、インターネット全体にユーザーがいる場合でもこれを行うことができます。

Windows Authentication管理者アクセスに使用します。これは、一般的なエンドユーザーに適用されるものから認証を分離しながら、管理領域を保護する最も実用的な方法です。システム管理者は、管理ユーザーのアクセス資格情報を管理し、ドメインユーザーアカウントにパスワードポリシーを適用します。

厳密な方法は、データベース、サーバー、およびすべてを含む2つの完全に異なる "ファーム"を用意し、データを1つのファームから別のファームに移動することです。最新の大規模システムのほとんどがこのアプローチを使用しています（ビネット、SharePointなど）。通常、「編集ステージ」->「プレビューステージ」->「配信ステージ」と呼ばれます。この方法では、コード（dev-> qa-> prod）と同じ方法でcontent / configを処理できます。

それほど偏執狂的でない場合は、単一のデータベースを使用できますが、「編集」サーバーで使用できるのは管理セクションのみです。つまり、編集サーバーに置かれているのは編集スクリプト/ファイルのみです。

当然のことながら、編集段階はローカルイントラネット上またはVPNを使用してのみ利用できます。

これは少しやり過ぎに見えるかもしれませんが、すべての使用例にとって最も簡単な解決策ではないかもしれませんが、物事を行うための最も確実な方法です。

「強力な管理者パスワードを持っている」などの方法は便利ですが、管理者はあらゆる種類のスマートな攻撃に開放されたままであることに注意してください。

保護するデータの種類（法的要件など）に大きく依存します。

• 提案の多くは認証に関するものです。ログインとしてOpenId / Facebook認証を使用することを検討する必要があると思います。（彼らはおそらくあなたよりも認証セキュリティに多くのリソースを費やすでしょう）

• 変更を保存するとともに、データベースの値を更新します。これにより、ユーザーXから、または日付XとYの間の変更をロールバックできます。

管理者パスワードの保存/検証について言及している人は誰もいませんでした。PWをプレーンテキストで保存しないでください。できれば元に戻すことができるものも含めないでください。少なくとも、誰かがたまたま保存されている「パスワード」を取得した場合に備えて、ソルト MD5ハッシュのようなものを使用してください。彼らがあなたのソルトスキームも持っていない限り、ものすごく便利なもの。

パスワードフィールドと、最初のガールフレンドの名前など、管理者が知っているセキュリティの質問を追加するか、管理パネルを表示するたびに質問をランダム化します。

おそらく、管理セクションを大きなディレクトリに常に置くことができます。

http://domain.com/sub/sub/sub/sub/sub/index.php

しかし、それは本当に良いことではありません。

おそらく、次のようにホームページにクエリ文字列を含めることができます。

http://domain.com/index.php?display=true

その場合、ユーザー名とパスワードのフィールドが表示されます。