OCI Certificates

解決する課題

• TLS 証明書の発行・更新・失効を手作業で管理しており、期限切れによる障害が起きる
• 社内システム向けにプライベート CAを構築・運用したいが、自前運用の負荷が高い
• 証明書の秘密鍵を安全に保管し、漏洩リスクを抑えたい
• ロードバランサや API ゲートウェイへの証明書の配布・差し替えを自動化したい
• 証明書の有効期限を監視し、更新漏れを防ぎたい

主要概念と用語

• Certificate（証明書）: TLS 通信でサーバ等の身元を証明する電子証明書。OCI が発行・管理する単位
• Certificate Authority（CA / 認証局）: 証明書に署名する主体。OCI Certificates ではプライベート CA を作成・運用できる
• Root CA / Subordinate CA: CA の階層。Root CA を頂点に、中間の Subordinate（下位）CA を配置して信頼チェーンを構成
• CA Bundle（CA バンドル）: 信頼すべき CA 証明書の集合。クライアント側が検証時に参照する
• Certificate Configuration Type（構成タイプ）: 証明書の出自。OCI が CA で発行するIssued by Internal CA、外部 CA で署名するManaged Externally（CSR 方式）、外部で取得済みの証明書を持ち込む**Imported（インポート）**の3形態
• Renewal（更新）: 有効期限前に証明書を自動更新する仕組み。内部 CA 発行の証明書で利用可能
• Revocation（失効）/ CRL: 証明書を無効化する操作と、失効リスト（Certificate Revocation List）の公開
• Version（バージョン）: 証明書や CA はバージョン管理され、更新ごとに新バージョンが作られる

仕様・制限・クォータ

• リージョン単位のサービス。証明書・CA はコンパートメント配下で管理する
• プライベート CA の秘密鍵は OCI Vault（KMS）の鍵で保護され、署名操作は鍵の境界内で行われる
• 構成タイプは大きく内部 CA 発行 / 外部管理（CSR）/ インポートの3種類。内部 CA 発行のみ自動更新に対応
• パブリックに信頼される証明書の自動発行は対象外で、本サービスは主にプライベート PKI とインポートに焦点を当てる
• ロードバランサ・API Gateway 等が証明書リソースを直接参照でき、差し替え時の再アップロードを不要にできる
• 削除した CA・証明書には**スケジュール削除（保留期間）**があり、誤削除から復元できる場合がある
• CA 階層の深さや1テナンシあたりの CA・証明書数には上限があり、詳細値は変動するため公式ドキュメントで確認する

内部の仕組み

OCI Certificates の中核はプライベート PKI（公開鍵基盤）の運用代行です。プライベート CA を作成すると、その CA の秘密鍵は OCI Vault の鍵で保護され、署名処理は鍵を外部に露出させずに実行されます。CA は Root CA を頂点とし、必要に応じて Subordinate CA を連ねて信頼チェーンを形成します。証明書を内部 CA から発行する場合、サービスが鍵ペア生成と CA 署名を行い、有効期限が近づくと自動的に新バージョンを発行して更新します。

ロードバランサや API Gateway などのコンシューマは、証明書を直接ファイルとして保持するのではなく、証明書リソースの OCID を参照します。更新で新バージョンができると、参照側は最新バージョンを取得できるため、証明書差し替えの手作業を削減できます。証明書・CA に対する操作はすべて OCI Audit にイベントとして記録され、誰がいつ発行・更新・失効したかを追跡できます。

設計パターン / ベストプラクティス

• 社内・サービス間通信はプライベート CA で証明書を発行し、相互 TLS（mTLS）や内部 HTTPS を統制
• Root CA はめったに使わず、日常の発行はSubordinate CAに委ねて Root の鍵露出を最小化
• 内部 CA 発行の証明書は自動更新を有効化し、期限切れ障害を構造的に排除
• ロードバランサ・API Gateway には証明書リソースをOCID 参照で関連付け、差し替えを無停止化
• 外部の公的証明書が必要な場合はインポート構成で持ち込み、更新時はバージョンを差し替える
• 環境（本番・検証）や用途ごとにCA とコンパートメントを分割し、ブラスト半径を限定
• 失効が必要になった証明書は速やかにRevoke し、CRL を最新化

運用・監視

• 証明書・CA の発行/更新/失効は OCI Audit で監査し、必要に応じて OCI Logging に連携
• Events サービスで有効期限が近い証明書や更新イベントを検知し、Notifications / Functions で自動通知・自動対応
• 自動更新が失敗した場合は Vault の鍵状態・IAM ポリシー・CA の状態（無効化・スケジュール削除中など）を確認
• 失効や CA ローテーションの際は、コンシューマ側（ロードバランサ等）が最新バージョンを参照しているかを確認
• 誤って削除した CA・証明書は、保留期間内であれば復元できる場合がある

コスト

具体的な単価は変動するため、最新の料金は公式の料金ページで確認してください。一般にCA 数を抑え、自動更新で運用工数を下げることがコスト最適化の基本方針になります。

セキュリティ

• プライベート CA の署名鍵は OCI Vault（KMS）の HSM 保護鍵で守られ、鍵は境界外に露出しない
• IAM ポリシーで最小権限を徹底し、CA を管理する権限と証明書を発行・利用する権限を分離
• Root CA の利用を最小化し、日常発行は Subordinate CA に限定して Root の露出を抑える
• 漏洩・不要になった証明書は速やかに**失効（Revoke）**し、信頼チェーンの健全性を維持
• すべての PKI 操作を OCI Audit で追跡可能にする

Well-Architected の観点

• セキュリティ: プライベート PKI を一元管理し、署名鍵を Vault で保護。IAM による最小権限と Audit による追跡で、証明書の発行・失効を統制できる
• 自動更新により期限切れに起因する可用性低下を防ぎ、結果として信頼性にも寄与する
• 証明書差し替えの自動化は運用負荷の軽減につながり、ヒューマンエラーを減らす

試験で問われるポイント

関連サービス・比較

ハンズオン / CLI例

# 1. プライベート ルート CA を作成（署名鍵は Vault の鍵で保護）
oci certs-mgmt certificate-authority create-certificate-authority-create-root-ca-by-generating-internally-config-details \
  --compartment-id <compartment-ocid> \
  --name app-root-ca \
  --kms-key-id <vault-key-ocid> \
  --subject '{"commonName":"app-root-ca.example.internal"}' \
  --validity '{"timeOfValidityNotAfter":"2030-01-01T00:00:00Z"}'

# 2. 内部 CA で TLS サーバ証明書を発行（自動更新を有効化）
oci certs-mgmt certificate create-certificate-issued-by-internal-ca-config-details \
  --compartment-id <compartment-ocid> \
  --name app-server-cert \
  --issuer-certificate-authority-id <ca-ocid> \
  --subject '{"commonName":"app.example.internal"}'

# 3. 証明書のバージョン一覧を確認
oci certs-mgmt certificate-version list-certificate-versions \
  --certificate-id <certificate-ocid>

# 4. 不要になった証明書バージョンを失効（Revoke）
oci certs-mgmt certificate-version revoke-certificate-version \
  --certificate-id <certificate-ocid> \
  --certificate-version-number 1 \
  --revocation-reason SUPERSEDED

# 5. 証明書の内容（証明書チェーン等）を取得
oci certificates certificate-bundle get-certificate-bundle \
  --certificate-id <certificate-ocid>