Confluence のセキュリティ設定のベスト プラクティス
べスト プラクティス
このガイドのすべてがお客様の環境に当てはまるわけではありませんが、説明されている原則はほとんどの環境に適用できます。
これらのプラクティスに従っても、100% のセキュリティを提供できるわけではない点にご注意ください。システムが危険にさらされた場合に、影響を軽減して侵入者の動きを抑制する措置になります。
アドバイザリー アラートを購読する
アドバイザリー アラートを購読して技術担当者の詳細情報を最新に保ち、セキュリティ アドバイザリー アラートとその他の重要な技術的な最新情報を確実に受け取ってください。
インストール ディレクトリとデータ ディレクトリの保護
Confluence インストール ディレクトリ、ホーム ディレクトリ、および添付ファイル、スペースのエクスポート、またはデータ パイプラインのエクスポート用に定義できるストレージの場所の安全性を確認することが重要です。
次を実行することを強くお勧めします。
- 専用の非 root ユーザー アカウントで、Confluence を実行する。
- Confluence ディレクトリにアクセスできるユーザー アカウントを制限する。
実行する方法については、「オペレーティング システム上に Confluence 実行専用のユーザー アカウントを作成する」をご確認ください。
バイナリも監視する必要があります。攻撃者がシステムのあるアカウントに不正アクセスする場合は、通常、他のアカウントにもアクセスしようとするものです。これを目的に、攻撃者はシステムのファイルを変更するなど、悪意のあるコードを追加する場合があります。悪意のある変更が行われていないことを定期的に確認できる方法をご検討ください。
データベースを保護する
Confluence データベースのユーザー (およびすべてのデータソースのデータベース ユーザー) が、本当に必要な範囲のデータベース権限しか持たないようにします。
データベース アクセスを Confluence ホストのみに制限します (iptables または組み込みのデータベース セキュリティ ツールを使用)。これを行う方法については、ご利用のデータベースのドキュメントをご確認ください。
管理者機能へのアクセスを制限する
原則として、Confluence 管理者の数をできるだけ少なくして、これらのユーザー アカウントを一つひとつ頻繁に確認することで、アクセス レベルを適切な状態に維持してください。
- 管理者アカウントやユーザー アカウントの共有や、「admin」のような簡単に推測できるユーザー名は避けてください。
- 管理者に 2 つの個別のアカウントを用意して、ページの作成などの日常業務を管理タスクと分けられるようにします。
- confluence-administrators グループのユーザー数を制限します。この「スーパー グループ」のメンバーは、すべての管理機能にアクセスして、制限されたページを含むすべてのコンテンツにアクセスできます。このグループのメンバーを制限して、代わりにシステム管理者グローバル権限を持つ新しいグループを作成することをご検討ください。
confluence-administrators スーパー グループをご確認ください。
- セキュア管理者セッションを使用して、管理機能にアクセスする際のパスワードを再入力するように管理者に要求して、管理者セッションのタイムアウトを短い値に設定します。
セキュア管理者セッションを有効化する方法をご確認ください。
- Apache を使用して、管理インターフェイスを特定の IP アドレスに制限します。これは、利用するリバース プロキシのテンプレートとして使用できます。
Apache を使用して、Confluence 管理インターフェイスへのアクセスを制限する。
受送信接続を制限する
ファイアウォールやプロキシ サーバーなど、受送信接続を制限する方法はいくつかあります。
- 許可リストを使用して受送信接続を制限し、Server-Side Request Forgery (SSRF) 攻撃を回避します。Confluence は、外部サイトのコンテンツを表示するマクロなどで許可リストを利用しています。
許可リストを有効にする方法をご確認ください。
ユーザー アカウントを管理する
優れたユーザー管理プラクティスは、ユーザー アカウントの侵害を防ぐ際に役立ちます。
- シングル サインオンと 2 要素認証に向けて、Confluence と ID プロバイダを統合することをご検討ください。
利用可能なさまざまな SSO オプションをご確認ください。
- 統合には個人用アクセス トークンを使用します。これによって、API リクエストの認証で基本認証 (ユーザー名とパスワード) よりも安全な方法がユーザーに提供されます。
個人用アクセス トークンの管理方法をご確認ください。
- 基本認証を無効にします。シングル サインオンを設定している場合は、ログインと REST の各リクエストの基本認証を無効にできます。基本認証は、シングル サインオンや個人用アクセス トークンよりも安全性が低くなります。基本認証を無効にする方法をご確認ください。
- ユーザーが組織を離れた際に、ユーザー アカウントを無効にします。また必要に応じて、ユーザー アカウントを削除して、そのアカウントの名前を匿名化 ID に置き換えられます。
ユーザーの削除と無効化
- 強力なロールまたはグループ メンバーシップを持つユーザーの数を制限します。特に機密性の高いデータへのアクセス権を 1 部門だけに持たせる必要がある場合は、データへのアクセスをその部門のユーザーのみに制限します。セキュリティよりも利便性を優先してはいけません。不要なのに、機密データへのアクセス権をすべてのスタッフに与えてはいけません。
ログイン試行を制限して、アクセスとアクティビティを監視する
ブルート フォース攻撃やサービス拒否攻撃のリスクを軽減するためにできる手段がいくつかあります。
- Fail2Ban は、ブルート フォース攻撃のリスクを減らす際に役立ちます。
Fail2Ban を使用してログイン試行を制限
- レート制限を使用して、許可する理由がない匿名ユーザーからの REST API リクエストをブロック、または Dos 攻撃のリスクを軽減するためにリクエストの数を制限します。
レート制限を使用してリクエストをブロックする方法をご確認ください。
- 監査ログの設定をレビューして、管理者とエンド ユーザーの重要なアクションを記録していることを確認します。
監査ログに書き込めるイベントをご確認ください。
- アクセス ログは、異常なアクティビティを識別する際に役立ちます。ログはインストール ディレクトリに書き込まれます。お好みの監視ツールでこれらのログを監視することをお勧めします。
アクセス ログをご確認ください。
定期的なセキュリティ監査を実行
定期的なセキュリティ監査は潜在的な脅威の特定に役立つだけではなく、セキュリティ ポリシーと手順を見直す機会でもあります。
- セキュリティ侵害が発生した場合にサポートできる人を把握しましょう。潜在的な脅威が特定された場合のプロセスは何ですか?
- 「もしもの場合」を想定した計画演習を実行します。「休暇中に特権ユーザーのパスワードが盗まれた場合に起こり得る最悪のことは何ですか? 被害を最小限に抑えるにはどうすればいいですか?」といったことを検討します。
- セキュリティ対策を文書化して、すべての対策が引き続き実施されて適切であることを定期的に監視します。たとえば、アップグレードや移行後に、誰かが新しいシステムやバージョンにルールを適用し忘れる場合があります。
- メジャー アップグレードの準備では、セキュリティの確認を実施します。今こそ、現在の設定を現在の推奨事項と照らし合わせて確認する良いタイミングです。