テレポート パリティ: ゼロスタンディング特権アクセス モデル
静的認証情報 (開発者のラップトップや永続的な管理者ロールに分散されたローテーションされていない SSH 秘密キーなど) は、アカウント侵害後の横方向の移動の主なベクトルです。 BlackShield は、永続的なアクセスを、暗号的に制限された Just-In-Time (JIT) アクセス要求と一時的な OpenSSH 証明書に置き換えます。
1. ゼロスタンディング特権 (ZSP)
エンジニアは、デフォルトで非特権メンバー アカウントを維持します。昇格された運用アクセスは、タイムボックス化されたウィンドウに対して厳密にオンデマンドで許可されます。
2. 一時的な OpenSSH 認証局
有効期間が短い OpenSSH 証明書 (ssh-ed25519-cert-v01) を使用して、静的 SSH キーと Authorized_keys が EC2/Linux サーバー全体に広がるのを排除します。
3. 二重認証 JIT 承認
必須のチケット参照 (INC-9021 など) とビジネス上の正当な理由を使用してアクセスをリクエストします。管理者はリアルタイムで承認します。
4. 自動失効と失効
アクティブな許可は継続的にカウントダウンされます。 TTL が経過すると (30 分から 8 時間)、権限は資格情報が残らない状態で自動的に期限切れになります。
5. ターンキーホストのオンボーディング
Linux ホストには、BlackShield の CA を信頼する 1 行の標準 sshd_config ディレクティブのみが必要です。独自のエージェント デーモンは必要ありません。
6. 改ざん防止監査チェーン
暗号的に連鎖された監査ログは、すべてのリクエスト、レビュー、証明書作成イベントを SOC 2 CC6.1 および ISO 27001 証拠バンドルに直接リンクします。
1. ホスト構成 (OpenSSH sshd_config)
重いクライアント デーモンを必要とする従来の PAM ソリューションとは異なり、BlackShield は、すべての Linux ディストリビューションに組み込まれているネイティブの OpenSSH 証明書検証に依存しています。テナント CA 公開キーを /etc/ssh/blackshield_user_ca.pub:
# 1. Fetch tenant CA public key from the dashboard or API: curl -s https://api.blackshield.chaplau.com/api/v1/identity/access/ssh/ca | jq -r .ca_public_key > /etc/ssh/blackshield_user_ca.pub # 2. Tell sshd to trust user certificates signed by this CA: echo "TrustedUserCAKeys /etc/ssh/blackshield_user_ca.pub" >> /etc/ssh/sshd_config # 3. Reload OpenSSH daemon: systemctl reload sshd
2. 開発者クライアントの設定 (~/.ssh/config)
開発者は、すべての内部ホストに対して署名付き証明書を自動的に使用するように OpenSSH クライアントを構成できます。
Host *.internal IdentityFile ~/.ssh/id_ed25519 CertificateFile ~/.ssh/id_ed25519-cert.pub IdentitiesOnly yes
3. コンプライアンスと管理の証拠
| 標準 | コントロールID | 要件 | BlackShield 自動制御 |
|---|---|---|---|
| SOC 2 タイプ II | CC6.1 / CC6.2 | 論理アクセスは許可されたユーザーに制限されます | 常駐特権はゼロ。昇格されたロールには二重承認が必要 |
| SOC 2 タイプ II | CC6.3 | 論理アクセス認証情報のタイムリーな取り消し | 有効期限が自動化された、タイムボックス化された有効期限の短い証明書 (デフォルトは 60 分) |
| ISO27001 | A.9.2.6 / A.9.4.2 | 安全な認証と特権アクセス制御 | OpenSSH Ed25519 ユーザー証明書のハードウェアによる暗号化署名 |