[解決済み] ウェブサイトの管理画面を保護するためのベストプラクティスとは？[クローズド］

質問

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

もちろん、SSL の使用やすべてのアクセスのログ取得など、明白なことがありますが、これらの基本的な手順より上のレベルを人々がどのように考えているのか、疑問に思っています。

たとえば

• 通常のユーザーと同じ認証メカニズムに頼っているだけですか？ そうでない場合、何を？
• Admin セクションを同じ「アプリケーション ドメイン」で実行していますか？
• 管理セクションを発見されないようにするために、どのような手順を取りますか? (または、全体の「不明瞭さ」を拒否しますか)

今のところ、回答者からの提案は以下の通りです。

• ブルートフォース攻撃を防ぐために、各管理者パスワード チェックに人工的なサーバー側の一時停止を導入する。 [デベロッパー アート] を参照してください。
• 同じDBテーブルを使用するユーザーと管理者用に別々のログインページを使用する（管理領域へのアクセスを許可するXSRFとセッション・スティールを阻止するため）。 [シーフ マスター] を使用します。
• 管理領域にウェブサーバーネイティブ認証を追加することも検討します (例: .htaccess 経由)。 [シーフマスター] を使用する
• 管理者ログインに何度も失敗した後、ユーザーの IP をブロックすることを検討します。 [シーフマスター］
• 管理者ログインに失敗した後にキャプチャを追加する [シーフ マスター］
• 管理者だけでなく、ユーザーに対しても同様に強力なメカニズム（上記のテクニックを使用）を提供する（例：管理者を特別扱いしない）。 [Lo'oris] (ロリス)
• セカンドレベル認証の検討 (クライアント証明書、スマートカード、カードスペースなど) [JoeGeeky]を使用します。
• 信頼できるIP/ドメインからのアクセスのみを許可し、可能であれば基本的なHTTPパイプラインに（HttpModulesなどによる）チェックを追加する。 [JoeGeeky] を使用します。
• [ASP.NET] IPrincipal & Principal のロックダウン (不変かつ非列挙型にする) [JoeGeeky] を使用する。
• 権限の昇格をフェデレートする - 例えば、いずれかの管理者の権限がアップグレードされたときに他の管理者に電子メールを送信します。 [JoeGeeky] を使用します。
• 管理者のためのきめ細かい権利の検討 - たとえば、ロールベースの権利ではなく、管理者ごとの指標となるアクションのための権利を定義します。 [JoeGeeky]です。
• 管理者の作成を制限する - たとえば、管理者は他の管理者アカウントを変更または作成できません。 このためにロックダウンされた 'superadmin' クライアントを使用します。 [JoeGeeky]を使用します。
• クライアントサイド SSL 証明書、または RSA タイプのキーフォブ (電子トークン) の検討 [Daniel Papasian] を参照してください。
• 認証にクッキーを使用する場合、管理セクションを別のドメインに置くなどして、管理ページと通常のページに別々のクッキーを使用してください。 [Daniel Papasian] を参照してください。
• 現実的であれば、管理サイトを公共のインターネットから離れたプライベートなサブネットに置くことを検討してください。 [John Hartsock] を参照してください。
• ウェブサイトの管理者／通常使用のコンテキスト間を移動する際に、認証／セッションチケットを再発行するようにしました。 [リチャード JP ルグエン] を参照してください。

どのように解決するのですか？

これらはすべて良い答えです... 私は一般的に、管理セクションにいくつかの追加レイヤーを追加するのが好きです。私はテーマについていくつかのバリエーションを使用してきましたが、一般的には次のうちの 1 つを含んでいます。

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