mcpField
P
pki-design

pki-design

github.com/vinayaklattheセキュリティ17880 回インストール19 週間前に更新
リポジトリ

pki-design について

Azure 中心またはハイブリッド環境で証明書を設計する、セキュリティおよびプラットフォームチーム向けの PKI ガイダンススキルです。CA 階層、鍵の保護、自動更新、失効を扱い、サービス TLS、デバイス ID、コード署名、S/MIME に対応します。

主な機能

  1. 01オフラインルート CA と発行 CA の設計
  2. 02HSM による鍵保護の計画
  3. 03証明書の自動更新設定
  4. 04ユーザー・デバイス証明書の展開計画
  5. 05CRL と OCSP による失効設計
  6. 06有効期限とローテーションの監視

活用シーン

  1. 01サービス向け内部 TLS または mTLS の設計
  2. 02Entra 証明書ベース認証の計画
  3. 03Intune SCEP または PKCS 証明書の展開
  4. 04証明書の期限通知と更新手順の構築

インストール

コマンドをコピーしてターミナルで実行します。

$npx skills add https://github.com/vinayaklatthe/microsoft-security-skills --skill pki-design

インストール後、Claude Code で/pki-designを入力して読み込まれたか確認します。

詳細

PKI 設計

公開鍵基盤（PKI）は、認証、暗号化、署名を支えるデジタル証明書を発行・管理します。Azure 中心の環境やハイブリッド環境では、信頼された CA 階層、Key Vault ストレージ、自動化されたライフサイクル、証明書ベースの認証を組み合わせます。

使用する場面

Entra のフィッシング耐性のある CBA、サービス向け TLS／mTLS、デバイス ID（Wi-Fi 802.1x、VPN）、コード署名、S/MIME の証明書発行、配布、ライフサイクルを設計するときに使用します。「証明書はどこから取得し、どのように更新するのか」という質問にはこのスキルを使用します。「シークレットを 1 つ保存するにはどうすればよいか」という質問には使用しません。

Key Vault のシークレット／キー（azure-key-vault）または Entra ID モデル（entra-id）には、このスキルを使用しないでください。

用途に応じて CA 戦略を選択する

用途が次の場合CA の選択肢備考
インターネットに公開する TLS（Web サイト、API）パブリック CA（DigiCert、GlobalSign、Let's Encrypt）常に使用します。プライベート CA はブラウザーから信頼されません
内部アプリの TLS、mTLS、サービス間通信内部 発行 CA（AD CS またはマネージド型）内部で信頼されるプライベート CA チェーン
Entra の証明書ベース認証Entra の信頼ストアに公開された内部 CA強力なバインド ポリシーと組み合わせます
デバイス ID（Wi-Fi 802.1x、VPN）AD CS またはサードパーティ PKI ＋ Intune SCEP／PKCS自動登録が不可欠です
コード署名パブリック CA の EV コード署名証明書ハードウェアトークンを使用し、厳重に保護します
S/MIME メールの署名／暗号化サードパーティのパブリック CA（DigiCert、Sectigo）内部 CA は外部の受信者から信頼されません
有効期間の短いワークロード証明書（Kubernetes）ACME または内部発行元を使用する cert-managerTTL は数分から数時間

経験則： インターネットに公開するサービスにプライベート CA を使用せず、大規模な内部証明書にパブリック CA を使用しないでください（コストと柔軟性のため）。2 つの異なるチェーンを使用します。

アプローチ

  1. CA 階層を設計する — オフラインルート CA ＋ 1 つ以上のオンライン 発行 CA を用意します。 ルート CA は発行 CA の証明書に署名し（有効期間は長く、たとえば 10～20 年）、発行 CA はエンドエンティティ証明書に署名します（有効期間は 1～2 年）。 確認方法：CRL への署名と発行 CA の更新を除き、ルート CA のホストが電源オフ、またはエアギャップ状態であることを確認します。

  2. HSM で鍵を保護する — ルート CA の秘密鍵は HSM（FIPS 140-2 Level 2 以上）に格納します。クラウドネイティブ環境では Azure Managed HSM、AD CS ではオンプレミスの HSM を使用します。保護されていないファイルシステムには絶対に格納しないでください。 確認方法：certutil -getreg ca\CSP\Provider に HSM プロバイダーが表示され、「Microsoft Software Key Storage Provider」と表示されないことを確認します。

  3. Key Vault でストレージとライフサイクルを管理する — すべてのサービス証明書に Azure Key Vault certificates を使用します。サポート対象の発行 CA（DigiCert、GlobalSign、Key Vault Acmebot またはパートナーコネクタ経由の内部 CA）と統合し、自動更新を有効にします。 確認方法：証明書オブジェクトで lifetime_actions が設定され、有効期間の 75% に達した時点で自動更新されることを確認します。手動操作が必要なのは、新規発行時のみです。

  4. デバイス証明書とユーザー証明書の自動登録を設定する — ドメインメンバーには GPO 経由で AD CS の自動登録を使用し、クラウド管理デバイスには Intune SCEP または PKCS connector を使用します。PFX ファイルをメールで送信してはいけません。 確認方法：Intune の証明書プロファイルで 95% を超える展開成功率が報告され、ユーザー証明書またはデバイス証明書が個人ストアに表示されることを確認します。

  5. 失効を計画する — CRL（Certificate Revocation List）を HTTP エンドポイントに公開し、リアルタイム確認用に OCSP レスポンダーを用意します。どちらも高可用性が必要です。CRL にアクセスできない場合、高保証証明書を使用する最新のクライアントはフェイルクローズします。CRL の HTTP エンドポイントには CDN を使用します。 確認方法：CRL エンドポイントにパブリックインターネット（外部証明書を使用する場合）およびすべての内部クライアントからアクセスでき、OCSP レスポンダーの稼働率が 99.9% を超えていることを確認します。

  6. 有効期限を監視する — Key Vault から有効期限が近づいたことを知らせるイベントを送信し、ダッシュボードにストリーミングします。AD CS では、スケジュールに従ってスクリプト（certutil -view）を実行します。90／60／30／7 日前の時点を追跡します。 確認方法：本番環境の証明書が監視されないまま期限切れになることがなく、有効期限の 60 日前にアラートが発報されることを確認します。

  7. ローテーションを徹底する — 有効期限が近づいてからではなく、発行前にローテーションを計画します。サービスチームは更新の自動化を担当し、PKI チームは CA とアラート基盤を担当します。

ガードレール

  • ルート CA は常時オフラインにします。 ルートが侵害されると、過去に署名した、または今後署名するすべての証明書の信頼が損なわれます。電源オフ ＞ エアギャップ ＞ ネットワークから隔離した VM の順です。
  • 発行 CA の鍵には HSM を使用します。 ソフトウェアに格納された発行 CA の鍵は、信頼全体が失われる単一障害点です。
  • 本番証明書を、気付かないうちに期限切れにさせてはいけません。 最悪のタイミングで障害が発生します。自動更新するか、期限の 60 日前にアラートを出します。
  • 証明書に依存する前に失効を計画します。 CRL／OCSP が正常に機能しない証明書システムでは、実際に証明書を失効させることができません。つまり、侵害された証明書は期限切れまで有効なままです。
  • インターネット向け TLS には、必ずパブリック CA を使用します。 ブラウザーはプライベートチェーンを信頼しません。
  • セキュリティドメインをまたいでワイルドカード証明書を使用しないでください。 1 つが侵害されると、すべてのサブドメインが侵害されます。サービスごとに証明書を発行し、更新を自動化します。
  • コード署名鍵にはハードウェアトークンを使用します。 ソフトウェアで署名するコード署名鍵は、盗まれるとマルウェアに悪用されることが頻繁にあります。

よくあるアンチパターン

  • 「PFX を開発者にメールで送っただけです」 - キーが漏えいします。Key Vault とマネージド ID／SCEP を使用してください。
  • 「ルート CA はオンラインなので、発行 CA の証明書を簡単に更新できます」 - 利便性のために信頼チェーン全体を危険にさらしています。ルート CA はオフラインにしてください。
  • 「発行 CA にソフトウェア CSP を使います。HSM は高価です」 - ハードウェアの費用は、CA キーが盗まれた場合のインシデント対応費用よりも安く済みます。
  • 「更新が大変なので、エンドエンティティ証明書の有効期間を 5 年にします」 - 有効期間の長い証明書は、侵害された場合に大きなリスクとなります。有効期間を短くし、自動化してください。
  • 「CRL は社内ネットワーク内の単一サーバーにあります」 - 外部ユーザーは検証できず、CRL の停止によって認証ができなくなります。CDN を利用してください。
  • 「証明書を発行してから監視を設定します」 - 監視を設定する前に、必ず証明書の有効期限切れによるインシデントが発生します。
  • 「すべての環境（開発／テスト／本番）で同じ証明書を使います」 - 開発環境の証明書が侵害されると、本番環境にも影響します。環境ごとに証明書を用意してください。

プロンプトの例

  • オフラインルート CA と 2 つの発行 CA を備え、HSM でキーを保護する PKI 階層を設計してください。
  • App Service ワークロード向けに Azure Key Vault から証明書を発行し、自動ローテーションするようにしてください。
  • 内部 CA と強力なバインドを使用して、Entra の証明書ベース認証を設定してください。
  • Wi-Fi 802.1x 向けに Intune 経由で SCEP／PKCS 証明書を展開する計画を立ててください。
  • 内部 CA の CRL と OCSP を設定し、CDN を利用した CRL エンドポイントを構成してください。
  • Key Vault と AD CS 全体で証明書の有効期限を監視し、自動でアラートを送信してください。

Microsoft Learn

コメント

Markdown 対応