PHP Authentication Shield
Drupalサイトを不正アクセスから保護するためのシンプルなHTTP Basic認証シールドを作成し、サイトを「閉鎖的な庭園」として扱います。
shield
インストール
composer require 'drupal/shield:8.x-1.8'
composer require 'drupal/shield:8.x-1.6'
概要
Shieldは、DrupalサイトにシンプルなHTTP Basic認証シールドを作成するPHP認証モジュールです。訪問者がコンテンツにアクセスする前にユーザー名とパスワードの入力を要求することで、ウェブサイトを保護します。これは、開発環境、ステージング環境、または公開前のサイトを一般アクセスから保護しながら、認可されたチームメンバーが作業できるようにするのに特に便利です。
このモジュールは、Drupalのページキャッシュより前に実行されるミドルウェアレイヤーを通じてすべての受信HTTPリクエストをインターセプトし、キャッシュされたページでも適切な認証なしにはアクセスできないことを保証します。Shieldは、組み込みの設定、安全なパスワード保存のためのKeyモジュールとの統合、およびユーザー名とパスワードの両方を単一の安全なKeyに保存するためのマルチバリューKey対応など、複数の認証情報保存方法をサポートしています。
Shieldは、コマンドラインアクセス(Drush、cron)、特定のIPアドレスまたは範囲、HTTPリクエストメソッド(CORSに有用)、ドメイン名(バックオフィスを保護しながらフロントオフィスへのアクセスを許可)、および特定のパス(includeモードとexcludeモードの両方)など、さまざまな基準に基づいて認証をバイパスできる広範な例外処理機能を提供します。デバッグヘッダー機能は、特定のシナリオで認証が要求される理由または要求されない理由を管理者がトラブルシューティングするのに役立ちます。
Features
- 設定可能なユーザー名とパスワードによるDrupalサイト全体のHTTP Basic認証保護
- 複数の認証情報プロバイダーオプション:組み込みのShieldストレージ、Keyモジュール統合、またはセキュリティ強化のためのマルチバリューKeyモジュール
- Drush、cron、およびその他のコマンドライン操作を認証なしで許可するコマンドラインインターフェース(CLI)例外
- 認証をバイパスするための個別のIPアドレス、IPv6アドレス、およびCIDRネットワーク範囲をサポートするIPベースの許可リスト
- 特定のリクエストメソッド(GET、POST、OPTIONSなど)を認証から除外するHTTPメソッド許可リスト - CORSプリフライトリクエストに有用
- 特定のホスト名が認証をバイパスできるドメインベースの例外 - フロントオフィスを公開する必要があるマルチドメイン設定に最適
- パターンマッチングを使用したexcludeモード(リストされたパス以外すべてを保護)またはincludeモード(リストされたパスのみを保護)によるパスベースのフィルタリング
- 詳細なステータス情報を提供するデバッグヘッダー(X-Shield-Status):pending、authenticated、disabled、skipped (cli)、skipped (ip)、skipped (http method)、skipped (subrequest)、skipped (domain)、skipped (path)
- [user]と[pass]トークンをサポートするブラウザのログインダイアログに表示されるカスタマイズ可能な認証メッセージ
- 認証の競合を防ぐための自動ヘッダークリーンアップを備えたDrupalのBasic Authモジュールとの統合
- 環境固有の設定(ステージングでShieldを有効化、本番で無効化)のためのsettings.phpによる設定オーバーライドのサポート
- 自動設定変換によるDrupal 7 Shieldモジュールからの移行サポート
- キャッシュされたページが未認証ユーザーに提供されないようにページキャッシュの前にShieldが実行されることを保証する高優先度HTTPミドルウェア(優先度250)
- Shield設定変更時の適切なキャッシュ無効化を保証するキャッシュタグ統合
- パスベースの例外が内部パスとURLエイリアスの両方で機能することを保証するパスエイリアスサポート
- パスマッチングのための自動言語プレフィックス除去を備えた多言語サポート
Use Cases
開発またはステージングサイトの保護
Shieldは一般的に、開発環境とステージング環境を一般アクセスと検索エンジンのインデックス作成から保護するために使用されます。開発チームが知っている共有ユーザー名とパスワードでこれらの環境でShieldを有効にします。settings.phpの設定オーバーライドを使用して、他の環境で有効にしたまま本番環境でShieldを自動的に無効にします。例:$config['shield.settings']['shield_enable'] = (getenv('ENVIRONMENT') !== 'production');
保護されたバックオフィスを持つマルチドメイン設定
フロントオフィス(公開)とバックオフィス(管理)のドメインが別々のサイトでは、Shieldのドメイン許可リストを使用して、管理ドメインを保護しながら公開ドメインをアクセス可能に保ちます。公開ドメイン(例:www.example.com)をドメイン許可リストフィールドに追加すると、admin.example.comへのすべてのリクエストに認証が必要になります。
CORSサポートが必要なAPIエンドポイント
DrupalサイトがCORS要件を持つバックエンドAPIとして機能する場合、ブラウザは実際のAPI呼び出しの前にOPTIONSプリフライトリクエストを送信します。HTTPメソッド許可リストに「OPTIONS」を追加して、実際のデータリクエストを保護しながら、これらのプリフライトリクエストを認証なしで通過させます。
特定のパスのみの保護
Includeモードと特定のパスを使用して、サイトの特定の領域のみを保護します。たとえば、パスメソッドを「Include」に設定し、パスフィールドに/admin/*を追加することで、/admin/*パスのみを保護します。その他のすべてのページは公開アクセス可能になります。
自動化サービスの許可
CI/CDサーバーIP、監視サービスIP、またはCDNエッジサーバーIPでIP許可リストを設定して、認証情報なしの自動アクセスを許可します。たとえば、JenkinsサーバーのIPを追加して、認証プロンプトなしで自動デプロイを許可します。
Keyモジュールによる安全な認証情報保存
厳格なセキュリティ要件を持つ組織では、Keyモジュールと組み合わせてShieldを使用して認証情報を安全に保存します。ファイルベースまたは環境変数ベースのKeyを設定してデータベース外に認証情報を保存し、データベースダンプがShieldパスワードを公開しないようにします。
Tips
- settings.phpの設定オーバーライド($config['shield.settings']['shield_enable'] = FALSE;)を使用して、ステージング環境で有効にしたまま本番環境でShieldを無効にします。
- Varnishまたはその他のリバースプロキシキャッシングでShieldを使用する場合、キャッシュされたレスポンスが許可されていないIPに提供される可能性があるため、IP許可リストの使用を避けてください。
- 認証メッセージの[user]と[pass]トークンはセキュリティ上の理由からほとんどの最新ブラウザで表示されなくなっているため、認証情報の伝達に依存しないでください。
- CI/CDパイプラインでは、CIサーバーのIPを許可リストに設定するか、CLI例外を使用して認証なしで自動デプロイを許可します。
- 特にチームメンバーがプロジェクトを離れた場合や、意図した対象以外に認証情報が共有された可能性がある場合は、Shield認証情報を定期的にローテーションしてください。
- 環境変数または安全なファイルストレージを使用したKeyモジュールを使用して、認証情報をデータベースと設定エクスポートから除外します。
- 本番環境にデプロイする前に、デバッグヘッダーを使用してパスパターンをテストし、どのパスが保護されているかを確認します。
Technical Details
Admin Pages 1
/admin/config/system/shield
DrupalサイトのHTTP Basic認証保護を設定します。このページでは、管理者がShield保護の有効化/無効化、認証情報の設定、および認証をバイパスするタイミングを制御するさまざまな例外ルールを設定できます。
権限 1
Hooks 1
hook_help
ヘルプページでShieldモジュールのヘルプテキストを提供するためにhook_helpを実装します。
Troubleshooting 5
デバッグヘッダーオプションを有効にし、X-Shield-Statusレスポンスヘッダーを確認します。一般的な原因には以下が含まれます:IPが許可リストに含まれている、CLI例外がアクティブ、パスが除外されている、HTTPメソッドが許可されている、またはドメインが許可リストに含まれている。ヘッダーにはShieldがスキップされた正確な理由が表示されます。
これはbasic_authモジュールが有効で、Shield認証情報がbasic_authが検証しようとするパターンと一致する場合に発生します。Shield設定で「Basic認証ヘッダーを解除」がチェックされていることを確認し、basic_authがShield認証を妨害しないようにします。
Shieldはマッチングのためにパスエイリアスを内部パスに自動的に解決します。パスパターンには内部のnode/Xパスではなく、訪問者に表示される実際のURLパスを使用してください。
IP許可リストは、レスポンスがキャッシュされて許可されていないIPに提供される可能性があるため、リバースプロキシで問題を引き起こす可能性があります。リバースプロキシキャッシングを使用する場合はIP許可リストの使用を避けてください。X-Forwarded-Forヘッダーを転送するようにCDNを設定し、Drupalがプロキシを信頼するように設定されていることを確認してください。
認証情報プロバイダーの設定が認証情報の保存場所と一致していることを確認します。Keyモジュールを使用している場合は、Keyエンティティが存在し、有効な認証情報が含まれていることを確認します。ユーザー名/パスワードの入力ミスを確認してください。
Security Notes 7
- HTTP Basic認証の認証情報はbase64エンコーディング(暗号化ではありません)で送信されます。送信中の認証情報を保護するため、Shieldが有効な場合は常にHTTPSを使用してください。
- Shield認証情報はデフォルトでDrupal設定にプレーンテキストで保存されます。セキュリティを強化するには、Keyモジュール統合を使用してデータベース外に認証情報を保存してください。
- IP許可リスト機能は、攻撃者がクライアントIPアドレスを偽装できる場合にバイパスされる可能性があります。これは適切なプロキシ設定がない環境でより可能性が高くなります。
- Shieldは適切なアクセス制御の代わりにはなりません。シンプルなバリアを提供しますが、本当に機密性の高いデータを保護するために使用すべきではありません。
- Shieldに他のサービスやユーザーアカウントで使用されているのと同じ認証情報を使用することは避けてください。
- 設定をエクスポートする際、「shield」プロバイダーモードのShield認証情報がエクスポートに含まれることに注意してください。機密性の高い環境ではKeyモジュールを使用してください。
- [user]と[pass]トークンを使用すると認証メッセージでユーザー名とパスワードが漏洩する可能性がありますが、最新のブラウザは通常このメッセージを表示しません。