セキュリティ
Mezusphereはセキュリティをアーキテクチャとして扱います。設定として後付けするものではありません。プラットフォームのアウトバウンドのみの接続モデル、エッジでの認証適用、相互TLSが、デプロイ後に追加するのではなく構造的に保証されたセキュリティ特性を生み出します。
このセクションでは３つの領域を扱います：
- トランスポートセキュリティ：TLS 1.3、相互認証、Mezusphereの内部PKI
- 認証モデル：エッジでの認証適用、ルートごとのポリシー、アイデンティティ伝播
- データ保護：データの取り扱い、プライバシー原則、暗号化
アウトバウンドのみのセキュリティモデル
従来のインターネットサービスにはインバウンドスタックが必要でした。パブリックIPアドレス、オープンポート、ファイアウォールルール、リバースプロキシ、オリジンでのTLS終端。各レイヤーが攻撃対象領域を拡大します。
Mezusphereはこのモデルを反転させます。Warpgateがすべての接続を外向きに開始します。お客様のワークロードには：
- オープンポートなし：スキャン、プローブ、攻撃の対象がない
- パブリックIPアドレスなし：ワークロードを指すDNSレコードがない
- オリジン露出なし：従来のCDNやリバースプロキシ構成と異なり、攻撃者が直接狙える発見可能なオリジンIPがない
エンドユーザーのトラフィックはMezusphereのグローバルエッジから入り、TLS終端、認証、DDoS対策、ルーティングがリクエストがお客様のインフラに到達する前に適用されます。
多層防御
セキュリティポリシーは２つのレイヤーで適用されます：
- エッジでの適用：Mezusphereのグローバルエッジがリクエストを認証し、ルートポリシーを適用し、悪意のあるトラフィックを転送前にフィルタリング
- Warpgateでの検証：Warpgateがアップストリームワークロードへトラフィックを配信する前に、ルートとアイデンティティコンテキストを第二の防御ラインとして検証
このレイヤードアプローチにより、一方の適用ポイントが侵害されても、もう一方がワークロードを保護し続けます。
トランスポート暗号化
Mezusphereアーキテクチャのすべての接続は暗号化されています：
| 接続 | プロトコル | 認証 |
|---|---|---|
| エンドユーザー → Mezusphere エッジ | TLS 1.2+ | 自動HTTPS |
| Mezusphere エッジ → Warpgate | TLS 1.3 | 相互認証（mTLS）、双方を検証 |
| データプレーン ↔ コントロールプレーン | TLS 1.3 | 内部ワークロード認証 |
証明書はMezusphereの内部認証局が管理します。証明書のプロビジョニング、ローテーション、管理を行う必要はありません。
詳細はmTLSとTLS 1.3をご覧ください。
エッジでの認証
ルートで認証が有効な場合、Mezusphereはエッジでアイデンティティのライフサイクル全体を処理します：
- ログイン、サインアップ、パスワードリセットのフロー
- セッション管理とトークン検証
- ルートごとの認可ポリシー
- ワークロードへのアイデンティティコンテキスト転送
アプリケーションは信頼されたアイデンティティヘッダー付きの事前認証済みトラフィックを受信します。トークン検証ライブラリ、認証ミドルウェア、インテグレーションプロジェクトは不要です。
詳細は認証モデルをご覧ください。
データ保護
Mezusphereはリクエストトラフィックをエッジで処理し、ワークロードに転送します。アイデンティティデータ（ユーザーアカウント、ディレクトリ、認証情報）は暗号化された状態でコントロールプレーンに保存されます。
アウトバウンドのみのアーキテクチャにより、ワークロードのデータとインフラはプライベートに保たれます。Mezusphereがアプリケーションの内部状態、データベース、ファイルシステムへのアクセスを要求することはありません。
詳細はデータ保護をご覧ください。