AWS Resource Access ManagerでAWS Private CAを共有する場合のAWS管理アクセス許可設定をまとめてみました

初めに

AWS Private CA(Certificate Authority)は独自の認証局(CA)を生成可能なAWSのサービスです。

AWS Private CAを利用することで、社内システムでプライベートに使う様なドメインに対する証明書用のCAをAWS上でマネージドに管理しつつAWS Certificate Manager(ACM)と合わせて証明書の発行作業の簡素化、失効等の管理することができます。

AWS Private CAで発行したCAはResource Access Manager(RAM)で他アカウントに共有可能であり、これを用い適切に権限を委任することでシステムごとにアカウントが分かれても単一のルートCAからの派生として証明書を発行し集約的に管理可能です。

RAMでは共有設定時にアクセス許可を設定し共有先でどのような操作が可能かを設定する必要があります(必須)。

このアクセス許可設定にはAWSが提供する許可セットである「AWS管理アクセス許可」とユーザが独自で定義する「カスタマー管理アクセス許可」があり、AWS Private CA共有時は「AWS管理アクセス許可」のみが設定可能です。
(厳密には「カスタマー管理アクセス許可」は利用できないという表現が正しい)

https://docs.aws.amazon.com/ja_jp/ram/latest/userguide/security-ram-permissions.html

https://docs.aws.amazon.com/ja_jp/ram/latest/userguide/shareable.html#shareable-pca

さて、この「AWS管理アクセス許可」についてですがどうも調べてみてもAWSの公式ドキュメントでまとまっているものがなさそうで、いざ一覧見てもパッとどれが適切なんだ？となったので整理して備忘録としてまとめておきます。

なおこの内容は本記事執筆時点(2025/04/01)にマネジメントコンソールで確認した値に基づいているためご注意ください。確認時点はいずれのアクセス許可のデフォルトバージョンは「バージョン1」となっておりました。

一覧

現時点(2025/04/01)においてPrivate CAのRAMでの共有時に設定できるAWS管理アクセス許可は以下の７つです。
(後続の説明の関係でマネジメントコンソールの表示と記載で順序を変えてます)

• AWSRAMDefaultPermissionCertificateAuthority
• AWSRAMBlankEndEntityCertificateAPIPassthroughIssuanceCertificateAuthority
• AWSRAMBlankEndEntityCertificateAPICSRPassthroughIssuanceCertificateAuthority
• AWSRAMEndEntityClientAuthCertificateIssuanceCertificateAuthority
• AWSRAMEndEntityServerAuthCertificateIssuanceCertificateAuthority
• AWSRAMSubordinateCACertificatePathLen0IssuanceCertificateAuthority
• AWSRAMRevokeCertificateCertificateAuthority

マネジメントコンソールで表示時にデフォルトで設定されているのはAWSRAMDefaultPermissionCertificateAuthorityです。

実際に共有する際の設定プルダウンでも確認できます。

違いは利用できる証明書テンプレートのみ(ほぼ)

さて、このアクセス許可セットですが実は許可されるアクション自体は7つ中6つは同一です。
AWSRAMRevokeCertificateCertificateAuthorityのみ全く別ですのでこれは後ほど個別に確認します。

これら6つですが該当CA証明書の参照系権限の付与及びそこからの証明書発行ができる点は共通ですが、acm-pca:issueCertificate(証明書の発行)で利用可能な証明書テンプレートが異なります。

マネジメントコンソール上の操作では直接指定しないためあまり意識することはないのですがAWS Private CAで発行したCAを元に各種証明書を発行する場合種類に応じて適当な「証明書テンプレート」を元に証明書が発行されます。

https://docs.aws.amazon.com/ja_jp/privateca/latest/userguide/UsingTemplates.html

「証明書テンプレート」は証明書に発行されるパラメータセットのようなもので、アクセス許可設定でこれが指定されることで結果的に発行可能な証明書種別の制限となります。

さて、ここからはX.509の仕様(RFC 5280)との睨めっこです頑張っていきましょう。以降同RFCと呼ぶ場合もしくは引用セクションに引用元URLを記載していない場合は以下文書からの引用と見てください。

https://datatracker.ietf.org/doc/html/rfc5280

まとめ

AWSRAMRevokeCertificateCertificateAuthority以外のアクセス許可の違いはほぼ発行できる証明書の種類のみです。

• AWSRAMDefaultPermissionCertificateAuthority
  • EndEntityCertificate/V1
  • Webサーバ証明書、クライアント証明書として機能するX.509証明書の発行を許可
  • 下位CAは作成不可(エンドエンティティ証明書)
• AWSRAMBlankEndEntityCertificateAPIPassthroughIssuanceCertificateAuthority
  • BlankEndEntityCertificate_APIPassthrough/V1
  • 鍵用途及び鍵拡張に制限なくX.509証明書の発行を許可
  • 下位CAは作成不可(エンドエンティティ証明書)
• AWSRAMBlankEndEntityCertificateAPICSRPassthroughIssuanceCertificateAuthority
  • BlankEndEntityCertificate_APICSRPassthrough/V1
  • 大枠は上記と同様
  • ただしCRL配布ポイントは元のCAからのみではなくCSRからも継承可能
• AWSRAMEndEntityClientAuthCertificateIssuanceCertificateAuthority
  • EndEntityClientAuthCertificate/V1
  • クライアント証明書として機能するX.509証明書の発行を許可
  • CRL配布ポイントは元のCAからのみではなくCSRからも継承可能
  • 下位CAは作成不可(エンドエンティティ証明書)
• AWSRAMEndEntityServerAuthCertificateIssuanceCertificateAuthority
  • EndEntityServerAuthCertificate/V1
  • サーバ証明書として機能するX.509証明書の発行を許可
  • 下位CAは作成不可(エンドエンティティ証明書)
• AWSRAMSubordinateCACertificatePathLen0IssuanceCertificateAuthority
  • SubordinateCACertificate_PathLen0/V1
  • 下位CA用の証明書の発行を許可
    • ただしその下位CAからさらに派生した下位CAの作成は許可されない
  • ベストプラクティス的にはこれで共有し、共有先で下位CAを生成しそこからエンドエンティティ証明書を発行
    • ただし費用等とトレードオフ
• AWSRAMRevokeCertificateCertificateAuthority
  • 共有したCAの失効操作を許可
  • 発行権限はないので下位CA発行アカウント->親アカウントへの逆共有で失効の集約管理用？

では詳細を順に見ていきましょう。ドキュメントは日本語ページだと翻訳されないで欲しいところがされてしまう場合もあるのでドキュメントを見る場合は英語ページ推奨です。

本記事はX.509証明書の仕様を詳細に目的とする記事ではないので、共通部等あえて触れる必要のない値省略します。

AWSRAMDefaultPermissionCertificateAuthority

マネジメントコンソールで進める場合にデフォルト選択されているポリシーになります(以降こちらをデフォルトと呼びます)。

このポリシーはEndEntityCertificate/V1テンプレートが許可されます。
ここから先はこれを基準に説明していきますのでまずはこれをじっくり見ていきましょう。

赤枠部分がテンプレートにより異なる箇所、それ以外はテンプレートによらず(概ね)共通ですので特筆すべきことがない限り以降は触れません。

このアクセスポリシーな証明書はALBやCloudFront等WebサーバでHTTPSのために利用するサーバ証明書、およびクライアント証明書認証で使う証明書を発行できます。

もう少し具体的な定義として言及すると下位CA(いわゆる中間CA)として機能しないエンドエンティティ証明書かつ、電子署名(digitalSignature)及び鍵暗号(keyEncipherment)に利用可能な証明書の発行を許可するようになってます。
またExtended Key Usage(EKU)で具体的な用途も縛られておりWebサーバ認証およびクライアント証明書としてのみに利用可能なように明示的に制限されていますのでそれ以外の用途としては使えません。

電子署名はともかく鍵暗号？と言われるとあまり馴染みがないかもしれませんが、一般的にHTTPS等々で使われるTLS通信用でALBやCloudFront等各種サービスでHTTPS用に発行する証明書という理解で概ね大丈夫です。
(TLSは共通鍵暗号の交換のために公開鍵暗号で最初に鍵を交換します。詳しくはTLSのネゴシエーションを調べてみてください)

BasicConstraints ::= SEQUENCE {
cA BOOLEAN DEFAULT FALSE,
pathLenConstraint INTEGER (0..MAX) OPTIONAL }

The cA boolean indicates whether the certified public key may be used to verify certificate signatures. If the cA boolean is not asserted, then the keyCertSign bit in the key usage extension MUST NOT be asserted. If the basic constraints extension is not present in a version 3 certificate, or the extension is present but the cA boolean is not asserted, then the certified public key MUST NOT be used to verify certificate signatures.

またエンドエンティティ証明書としてのみ許可するための値としてはBasic Constrainsのパラメータとなり、このテンプレートではcA=Falseすなわち下位CAとしてとして機能しない証明書の発行のみが許可される指定になります。

※ pathLenConstraintはAWSRAMSubordinateCACertificatePathLen0IssuanceCertificateAuthorityで改めて触れますがcA=Falseの場合は作用しない値と見てください。

Each extension in a certificate is designated as either critical or non-critical. A certificate-using system MUST reject the certificate if it encounters a critical extension it does not recognize or a critical extension that contains information that it cannot process.

A non-critical extension MAY be ignored if it is not recognized, but MUST be processed if it is recognized. The following sections present recommended extensions used within Internet certificates and standard locations for information.

なお一応Criticalについては必ず準拠すべき値(MUST)ですが、Criticalがついていない(non-critical)値の準拠はMAYなのでしても一応RFC違反にはなりません。

とは言いつつも準拠しないことにより各種サービス等で跳ねられる可能性はあるため基本的にはCritical以外も準拠する前提で設定値を検討しましょう。

AWSRAMBlankEndEntityCertificateAPIPassthroughIssuanceCertificateAuthority

こちらはBlankEndEntityCertificate_APIPassthrough/V1が許可されます。

デフォルトポリシー同様エンドエンティティ証明書の発行を許可しますが、Key Usage及びExtended key usageが指定されていないため用途は制限されません。

そのためデータを直接するS/MIMEでの利用、HTTP以外でのover TLS通信等にも利用が可能です。
現時点での仕様でいえば発行した証明書をエクスポートしてWEB用途以外にも色々ゴリゴリ使ってくのであればこれというイメージではあります。

AWSRAMBlankEndEntityCertificateAPICSRPassthroughIssuanceCertificateAuthority

(抜けてたので追記しました)

こちらはBlankEndEntityCertificate_APICSRPassthrough/V1が許可されます。

BlankEndEntityCertificate_APIPassthrough/V1と同様用途に制限なくエンドエンティティ証明書を発行可能ですが、CRL配布ポイントをCAからのみではなくCSRから継承する形で設定することが可能のようです。

..なんだこれ？

自分がCRLを概要レベルでしか知らないため不正確な可能性がありますが、通常証明書の失効はその発行主体であるCA側で行うためCA側の証明書に記載されてると認識してるのですがユーザ側主体で発行するCSRの値を採用させることが可能なようです。

https://datatracker.ietf.org/doc/html/rfc2986
CertificationRequestInfo ::= SEQUENCE {
version INTEGER { v1(0) } (v1,...),
subject Name,
subjectPKInfo SubjectPublicKeyInfo{{ PKInfoAlgorithms }},
attributes [0] Attributes{{ CRIAttributes }}
}
...
attributes is a collection of attributes providing additional information about the subject of the certificate. Some attribute types that might be useful here are defined in PKCS #9. An example is the challenge-password attribute, which specifies a password by which the entity may request certificate revocation. Another example is information to appear in X.509 certificate extensions (e.g. the extensionRequest attribute from PKCS #9).

https://datatracker.ietf.org/doc/html/rfc2985
The extensionRequest attribute type may be used to carry information about certificate extensions the requester wishes to be included in a certificate.

うーん...

https://datatracker.ietf.org/doc/html/rfc5280
4.2. Certificate Extensions
...
4.2.1.13. CRL Distribution Points

どういったケースで使うかあまりイメージはつきませんが仕様的にCRL配布ポイントはCertificate Extentionに含まれてますし、CSRの定義的にそれを含めることは可能なので証明書発行側がそれを許可すればできなくはなさそうです。

CRL利用して早期失効をしっかり管理したいけどどうしてもCAで共通定義されるCRL配布ポイントにアクセスできないような閉域環境が極一部にあって...とかでしょうか。柔軟性はありますがブラックボックス化しそうな部分もあり採用する場合はそれなりに管理コストはかかりそうです。

AWSRAMEndEntityClientAuthCertificateIssuanceCertificateAuthority

こちらはEndEntityClientAuthCertificate/V1が許可されます。

これはデフォルトのExtended Key UsageからTLS web server authenticationが抜けただけ、すなわちクライアント証明書としてのみ利用可能なエンドエンティティ証明書の発行を許可します。

(追記)前述のCRL配布ポイントの話を追記してて気づきましたが、こちらのテンプレートもCSRからCRL配布ポイントを継承可能なようです。

AWSRAMEndEntityServerAuthCertificateIssuanceCertificateAuthority

こちらはEndEntityServerAuthCertificate/V1が許可されます。

こちらは先ほどのとは逆にデフォルトからTLS web client authenticationが抜けており、WEBサーバ証明書としてのみ利用可能なエンドエンティ証明書の発行を許可します。

AWSRAMSubordinateCACertificatePathLen0IssuanceCertificateAuthority

こちらはSubordinateCACertificate_PathLen0/V1が許可されます。

こちらのテンプレートははここまでと異なりcA=Trueとなっており下位CA用の証明書を許可します。

A pathLenConstraint of zero indicates that no non-self-issued intermediate CA certificates may follow in a valid certification path.

ただしpathlen=0(pathLenConstraint=0)のため、ここで派生した下位CAはエンドエンティティ証明書の発行のみが許可され、さらに派生したCA証明書の作成は許可されません。

https://docs.aws.amazon.com/privateca/latest/userguide/template-definitions.html#SubordinateCACertificate_PathLen0-V1
Extended key usage is not included, which prevents the CA certificate from being used as a TLS client or server certificate.

またこのテンプレートはあくまで下位CAとしてのみ利用可能な証明書の発行を許可し、このポリシーで共有されている場合共有されたCAから直接エンドエンティティ証明書は発行できません。すなわち下位CAを挟みそこからエンドエンティティ証明書を発行することが強制されます。
赤枠いずれもCritical指定なのでかなり強い指定が入っています。

各アカウントに派生したCAを作成し管理を委任する場合にはこちらを指定して共有します。

一応管理やセキュリティ的にはアカウント毎に下位CAを発行しそこからエンドエンティティ証明書がベストプラクティスとなっていいますのでこのアクセス許可を利用するのが好ましくなりそうです(その単位で失効や配布等が管理可能)。

https://docs.aws.amazon.com/ja_jp/privateca/latest/userguide/ca-best-practices.html

ただしPrivate CAの発行には$400/月の費用が発生し(2025/04/01現在)、環境によっては決して小さい金額ではないので下位CAを設けるかは実情と合わせて検討しましょう。

AWSRAMRevokeCertificateCertificateAuthority

これが唯一証明書の発行権限を持たせない固有のアクセス許可設定になります。

こちらは対象のCA証明書の参照及び失効権限を与えることができます。
あくまでRAMで共有されたリソースに対する失効操作ですのでそこから各アカウントで派生した個別の下位CAやエンドエンティティ証明書のアクセス制御を指定するものではない点は注意しましょう。

https://docs.aws.amazon.com/ja_jp/privateca/latest/userguide/PcaRevokeCert.html

こちらはどちらかといえばルートCAに対して指定して共有するというよりは、下位CA側から集約管理アカウントに権限を与え何かあった場合に親側で下位CA単位でを強制的に失効させるような用途でしょうか。

終わりに

簡単にですがRAMでPrivate CAを共有する場合のアクセス許可設定を確認しまとめてみました。

証明書テンプレートを見たときは一瞬X.509と向き合わないとダメか...と思ってましたが、追ってみると極一部のパラメータのみ、ほぼ証明書の種類違いの指定だけで以外とサクッと頭に入るくらいのものでした。

０からやろうとするとちょっと初動が重い部分はありますが正確な理解が不要でざっくりでよければ「まとめ」のセクションくらいの情報量で足りると思いますので同じくあれ？となった方はご活用いただければ幸いです。