パブリック側に何を置くかを決めます。

1。人物とタスクを記述します。

各サービスについて、この文を完成させてください：「この役割の人は、この種のデバイスからこのアクションを実行する必要がある。」公開時刻表を読むこと、内部手順を編集すること、データベースを保守することは別のタスクです。1人のボランティアが時折リモートアクセスを必要とするという理由だけで、サービスを公開しないでください。

ネットワークアクセスとアプリケーション認証を分離します。ログインページに到達できることは、メンバーファイルを読む権限ではありません。逆に、サービスをプライベートネットワークの背後に隠しても、どのメンバーがそのコンテンツを編集またはエクスポートできるかは決まりません。両方の層と、誰かが離れたときにアクセスを削除するプロセスを記録します。

アカウント復旧も同じ議論に含めます。1人しか解除できないプライベートサービスは、初期のアクセスルールが制限的に見えても、別の障害を生み出します。

2。小さなアクセスマトリクスに記入します。

ここに仮想のコミュニティワークショップ設定を示します。選択肢は議論のための例であり、既製のネットワーク設計ではありません。

各行の横に実際のメカニズムを記入します：アプリケーションアカウント、承認されたプライベートアクセス方法、または別の文書化された制御。メカニズムとテストなしの「プライベート」は単なるラベルです。

3。ログインページ周辺の経路を確認します。

リバースプロキシ、アプリケーションリスナー、データベースポート、管理ツールをリストします。アプリケーションは慎重に設定されたログイン画面を持っていても、別のインターフェースが到達可能なままである可能性があります。変更する前にデプロイされた設定を検査し、リモートアクセスを制御するものについては復旧経路を保持します。

Docker が構成の一部になっている場合は、別途確認する価値があります。明示的なホストアドレスを指定しないポートマッピングは、通常すべてのホストアドレスで公開されます。ループバックバインドは、文書化されたデフォルトの NAT ケースではアクセスを制限しますが、ネットワークモード、直接ルーティング、古い Docker の挙動が影響します。実際のトポロジについてドキュメントを読み、使用している IPv4 および IPv6 のパスで到達可能性を確認してください。 Docker のポート公開とマッピング.

4。安心させるラベルではなく、実効的な制御を確認します。

ファイアウォールをネットワークルールを作成するソフトウェアと併せて確認します。Docker は、公開されたコンテナトラフィックが通常の UFW 入力ルール適用前に転送され得ることを文書化しています。したがって、UFW のステータスがきれいに見えても、コンテナポートにアクセスできないことの証明にはなりません。迅速な修正として Docker のファイアウォール管理を無効にしないでください。ドキュメントにはネットワーク上の影響が記載されています。 Docker パケットフィルタリングとファイアウォール.

アプリケーションのロールを個別に確認します。たとえば BookStack はロールの権限を組み合わせ、コンテンツレベルの上書きも許可するため、ユーザーの実効権限は割り当てられた 1 つのロール名とは異なる場合があります。割り当て全体を確認し、代表的なページと添付ファイルをテストしてください。 BookStack の権限ルール.

5。トランスポートと信頼を計画に含めます。

メンバー限定のサービスでも、認証情報と非公開コンテンツが含まれます。メンバーにブラウザの警告を無視するよう教えるのではなく、実際のクライアント向けに HTTPS と証明書の信頼を計画してください。証明書更新の担当と失敗時の確認を、ドメインアクセスと併せてノートブックに記載します。

Caddy のドキュメントでは、公開証明書の検証とローカル証明書認証局を区別しています。ローカル認証局の証明書を警告なしで使用するには、クライアントがその認証局を信頼する必要があります。公開証明書の場合、HTTP と TLS-ALPN の検証にはそれぞれのインバウンドパスが必要で、DNS 検証は別途設定する代替手段です。意図するアクセス境界に合う方式を選択してください。 Caddy の自動 HTTPS とローカル信頼.

これはアクセス計画の手順であり、証明書だけでアプリケーションが非公開または適切に認可されるという主張ではありません。

6。許可される経路と拒否される経路の両方をテストします。

サインアウトした訪問者、通常のメンバー、編集者に対して別々のブラウザセッションを使用します。通常のページ、ローカル添付ファイルの直接 URL、エクスポート操作、管理ルートを確認してください。アカウントを削除またはロールを変更した後に再テストします。予期しない成功を利便性と誤認しないよう、操作を試す前に期待結果を記録してください。

テストに使用する権限のあるネットワークから、公開サービスに到達でき、意図したプライベートインターフェースには到達できないことを確認します。解決先が異なる可能性のあるホスト名だけでなく、関連するアドレスファミリーと実際のエンドポイントをテストしてください。日付、送信元ネットワーク、結果を記録します。これらの確認はご自身の構成で実施する必要があり、ここで完了したとは主張しません。

機密の埋め込み画像を、サインアウト状態および権限のないメンバーで直接 URL からテストします。BookStack の画像はローカル添付ファイルと異なりデフォルトで公開されるため、ページを制限するだけでは不十分です。確認してください 画像のセキュリティ および アクセスガイドのストレージと権限の区別 境界を受け入れる前に。

7。失敗した境界は再検討する決定として扱います。

権限のないアカウントがデータを読める場合は、アクセス拡大を止め、ロール継承、共有、直接ファイルパスを確認してください。プライベートポートに到達できる場合は、推測で別のレイヤーを追加する前に、そのバインドとネットワークルールを見直します。本来の保守担当者が接続できない場合は、全員に広いアクセスを付与するのではなく、文書化された復旧手順を使用してください。

修正したルールと再現可能なチェックを次に記載します アクセスノートブック。これを次にリンクします サービスインベントリ と 復旧演習。これらの境界は、正しく実装されれば不要なアクセスを減らしますが、匿名性を約束するものではなく、更新と慎重なデータ取り扱いの必要性をなくすものでもありません。