デプロイメントをハードニングする

これは オペレーター向けのハードニングガイド です。コントロールプレーンをセキュアに実行するための具体的な手順を示します。説明ページの上に位置づけられます — セキュリティモデルと脅威モデルは、資産、信頼境界、そしてなぜポスチャが現状のようになっているかを説明します。このページは 方法（how） です。

1. セキュアなデフォルトを維持する

新規インストールはデフォルトでセキュアです。ここでの仕事は、ほとんどがそれを 弱めないこと です。

デフォルト	なぜ維持するか	オペレーターのアクション
デフォルトクレデンシャルなし	セルフホストにおける最大の落とし穴。初回起動時にワンタイム・単回使用のセットアップトークンを発行し、それで最初の管理者を作成します。	起動出力（またはコンテナログ）からトークンを読み取り、管理者を作成すると、それは消費されます。クレデンシャルをイメージに焼き込んではいけません。
デフォルトで TLS 有効	コレクター→コアおよびユーザー→パネルのチャネルは機密メタデータを運びます。	TLS は有効のままにします。`--insecure`（平文）はローカルホスト開発専用であり、露出したバインドでは決して使いません。
バインドは防御ではない	エンジンはデフォルトですべてのインターフェースにバインドします。これはサーバーだからです。守っているのは TLS 有効、デフォルト認証情報なし、単回使用のセットアップトークンであり、そのいずれもバインドには依存しません。	必要なら意図的に制限します：バイナリなら `--listen 127.0.0.1:8443`、Compose スタックなら `OLIVARES_BIND=127.0.0.1`。ブラウザが信頼する証明書とパスキーが受け付けるホスト名のために、自前のイングレス/TLS を前段に置きます — セルフホスティングを参照。
テレメトリのホームコールなし	ホームコールするセキュリティツールは負債です。	アクション不要 — エンジンは起動時に必須のアウトバウンド呼び出しを行いません。エアギャップモードでは egress はゼロです。

デフォルトからの危険な逸脱はすべて、名前付きの明示的なオプトイン です（たとえば開発用平文フラグ、または特権データベースロールの許可など）。あなたが設定しなかったなら、それはオフです。完全なセキュアデフォルトのポスチャと監査台帳の暗号学的保証はセキュリティモデルにあります。

サインインとセキュリティの設定

設定 → サインインとセキュリティを開くと、サインイン方法、エンジンのセッション有効期間、管理操作の追加認証ポリシー、登録済みパスキーを確認できます。セッション有効期間は読み取り専用で、セッションを更新すると有効期限が延長されます。このページでパスキーの登録・名前変更や認証アプリの登録を行います。システム管理者は既存の追加認証と認証アプリのポリシーを変更でき、その他のユーザーには追加認証の要件が編集コントロールなしで表示されます。パスキーや認証コードを必須にする前に、現在のセッションでそれを利用できることを証明する必要があります。シングルサインオンの設定にはアイデンティティプロバイダーを管理を使用してください。

リモートコレクター向けの相互 TLS

エッジコレクターは Business の機能です。Community ビルドは olivares collector を拒否します。以下の --grpc-client-ca フラグはコア側で設定します。

分散トポロジーでは、エッジコレクターはクライアント証明書検証済みの 相互 TLS でコアに観測をプッシュします。コアにクライアント CA を与えてクライアント証明書を 要求し検証 させることで、これを有効にします。

./bin/olivares serve \
  --listen 127.0.0.1:8443 --grpc-listen 127.0.0.1:8444 \
  --grpc-client-ca /path/to/collector-ca.pem \
  --data-dir /var/lib/olivares

コレクターは あなたの インフラ上で インバウンドリスナーなし（純粋なプッシュモデル）で動作するため、本番ホストにオープンポートを追加しません。データディレクトリ（監査署名鍵と TLS マテリアルを保持します）を保護しバックアップしてください（制限的なパーミッション）— そして監査公開鍵のマシン外コピーを保持してください。

2. 破壊的なアクションを human-in-the-loop の承認でガバナンスする

コントロールプレーンは デフォルト拒否（deny-by-default） の認可コアによってガバナンスされます（RBAC、加えて任意の restrict-only な Cedar/OPA の policy decision point。これはアクセスを 取り去る ことしかできず、決して拡大しません）。モデル — ロール、ポリシーシーム、記録された決定の保証 — についてはガバナンスと承認を参照してください。運用手順は次のとおりです。

承認ゲートを配線する。 インフラを変更するモジュールアクション（デプロイメントの apply、オーケストレーションの発火、ボイスの open）はすべて、正確なプランに紐づき、拒否クローズドで、時間制限された、ガバナンス対象の承認を開く human-in-the-loop の承認ゲートを通過します。これはブリッジの設定を提供することで有効になります。それがないと、これらのアクションは拒否クローズドのままです。
専用の承認者サービスアカウントを使う — 決して人間のものは使わない。 承認を開くコンポーネントは、 承認者プールに決して入らない、自身のサービスアカウント として実行されなければなりません。職務分掌はエンジン側で強制されます。リクエストを開いたアイデンティティはそれを決定できず、システムトークンは一切承認できません。開く側のアカウントが承認者でもある場合、ライブネスのデッドロックを作り出します — なので両者を分離してください。
承認者が決定し、台帳が記憶する。 認可された人間が承認または却下し、その決定は実際のアクターとともに同一トランザクションで改ざん検知可能な台帳に追記されます。期限切れのリクエストは拘束力のある決定を決して受け取れません。台帳が黙って忘れるようなガバナンス対象の変更を行うことはできません。

承認ルートはガバナンスモジュールの名前空間の下にあり、他のすべてと同じデフォルト拒否の RBAC と読み取りごとの監査の対象です。

3. 実行前にリリースを検証する

コントロールプレーンはセキュリティ製品です — 実行する前に、リリースがプロジェクトの公開したものであることを証明してください。完全なチェーン（チェックサム上の署名、SLSA プロベナンス、SBOM と OpenVEX アテステーション、オンラインキーレスまたは完全オフライン）はダウンロードしたものを検証するにあります。例外のない唯一のルールは次のとおりです。

4. 証跡 — そしてデータ — を自分のペリメータに保持する

台帳をマシン外にエクスポートする。 追記専用でハッシュ連鎖された Ed25519 署名付きの監査台帳は、複数の SIEM フォーマットで認証付きのプルエクスポートとして公開されます。これにより、あなたの SIEM または WORM ストアは、オフラインでチェーンを再検証する不変のコピーを保持します。マシン外コピーは、完全に侵害されたホストに対する真の対策です — 監査を Splunk に転送するを参照してください。
必須のテレメトリはなく、デフォルトではコントロールプレーンからのエグレスもない。 データプレーン（コレクター）は常にあなたのインフラ上で動作し、アクセスマップは リレーションのみを保存し、ペイロード、シークレット、PII は決して保存しません — 最小データは設定ではなくワイヤの性質です。あなたの境界を越えるのは、あなたがそのように設定したものだけです。具体的には、あなたのモデル API への呼び出し、接続した SIEM／Webhook 出力（上記のマシン外エクスポートを含む）、用意した場合の外部埋め込みプロバイダーです。これがデータレジデンシー、GDPR、エアギャップ運用の構造的な論拠です。これはアーキテクチャとあなたの設定の説明であり、保証ではありません。