Schema Registry のセキュリティ実装ガイド：認証・認可・ACL を正しく押さえる

Schema Registry は Avro/JSON Schema/Protobuf のスキーマ管理を提供しますが、REST 経由の読み書きと Kafka 内部の _schemas トピックの双方を安全化しない限り、改ざん・漏えい・互換性破壊のリスクが残ります。

本稿は、認証（REST）、認可（Subject 単位/RBAC）、Kafka ACL（_schemas）をひとつの導線で理解できるように整理。試験対策（CCDAK/CCAAK）で問われやすい設定キーや挙動も実務目線で補足します。

全体像と脅威モデル

Schema Registry の攻撃面は、大きく REST 層（クライアント→Schema Registry）と Kafka 層（Schema Registry→_schemas トピック）の2面です。前者は認証方式（mTLS/Basic/OAuth 等）と TLS で保護し、後者は Kafka 側の認証（SASL/SSL など）と ACL で制御します。Confluent Platform を使う場合、Subject 単位の認可に RBAC を適用できます。

脅威としては、盗聴（TLS 未設定）、なりすまし（認証不備）、権限過剰（認可/ACL 不備）、互換性破壊（無権限の削除/上書き）などが典型です。これらは REST と Kafka の両方で防御を組み合わせる必要があります。

• REST 層: HTTPS（必須）、クライアント認証（mTLS or Basic or トークン）
• Kafka 層: Schema Registry サービスアカウントでの認証、_schemas への最小権限 ACL
• 認可: Subject 単位の操作（READ/WRITE/DELETE）に RBAC またはオーサライザ
• 監査: アクセスログ、スキーマ変更履歴、運用フローの分離（本番/検証）

Schema Registry のセキュリティ境界

REST 認証（クライアント→Schema Registry）

REST 面の第一防御は TLS（HTTPS）です。その上で、クライアント認証は mTLS か Basic（+ 背後の LDAP/ファイルストア）を選ぶのが一般的です。Confluent Cloud では API Key/Secret（HTTP 認証ヘッダ）や OAuth/OIDC を使う構成もあります。

実務では、プロデューサ/コンシューマの SerDe が Schema Registry に直接接続するため、Kafka ブローカー向けのセキュリティ設定と、Schema Registry 向け（schema.registry.* 系）の設定が別物である点で混同が起きがちです。試験でもこの切り分けが頻出です。

• mTLS: 通信の相互認証。クライアント証明書の配布/ローテーションが前提。秘匿性と完全性が高い。
• Basic: ユーザー/パスワードを TLS 上で送る。Serializer 側で basic.auth.credentials.source を USER_INFO にするのが定番。
• Confluent Cloud: API Key/Secret による HTTP 認証、あるいは OIDC と統合したトークンベース。

クライアント（プロデューサ/コンシューマ）の典型設定例

# Kafka クライアントのプロパティ（Serializer/Deserializer が Schema Registry へ接続）
schema.registry.url=https://sr.example.local:8081

# Basic 認証（TLS 上で使用）。試験頻出キー：
basic.auth.credentials.source=USER_INFO
schema.registry.basic.auth.user.info=appuser:appsecret

# mTLS/サーバ検証。クライアント側トラストストア（自己署名 CA や社内 CA を含む）
schema.registry.ssl.truststore.location=/etc/security/truststore.jks
schema.registry.ssl.truststore.password=changeit

# クライアント証明書を要求される場合（相互 TLS）
schema.registry.ssl.keystore.location=/etc/security/keystore.jks
schema.registry.ssl.keystore.password=changeit

# 注意: これらは Kafka ブローカー接続用の ssl.* / sasl.* とは別物。両方を設定する必要があるケースが多い。

認可（Subject 単位）: RBAC とオーサライザ

Schema Registry では、Subject ごとに READ / WRITE / DELETE などの操作を制御します。Confluent Platform では MDS を用いた RBAC が利用でき、ユーザー/サービスアカウントに対して Subject リソースへの役割を付与します。これにより、本番系のスキーマを特定の CI/CD ロールのみが更新し、閲覧はより広く許可する、といった粒度の制御が可能です。

OSS 版（自己運用）では、内蔵/プラガブルなオーサライザで Subject 単位の制御を行う構成もあります。いずれの場合も、REST 認証で得られたプリンシパルが認可判定に使われ、許可されない操作は 403 Forbidden で拒否されます（401 は未認証）。

• 操作対象: Subject（例: payments-value）単位の READ/WRITE/DELETE
• 判定材料: REST 認証で確定したユーザー/SA のプリンシパル
• エラー識別: 401（未認証）と 403（認証済みだが権限不足）の区別

Kafka 側 ACL（_schemas トピック）

Schema Registry 自身は Kafka クライアントとして _schemas トピックへ読み書きします。ブローカー側で認証（SASL/SSL 等）を有効化している場合、Schema Registry のサービスアカウントに最小権限の ACL を付与します。

_schemas はコンパクション対象（cleanup.policy=compact）の内部トピックです。自動作成を無効化している環境では、事前に適切な設定で作成し、Schema Registry のみが読み書きできるようにします。

• 必要な ACL（例）: topic=_schemas に対する READ, WRITE, DESCRIBE
• グループ ACL: 実装により不要なことが多いが、運用ポリシーで Group を縛る場合は付与を検討
• RBAC を採用している場合は、対応する役割付与で置き換え（混在させない）
• トピック作成を禁止しているなら、管理者が _schemas を事前に作成

運用ベストプラクティスと監査

本番では、Schema Registry の REST アクセスログ、認証/認可ログ、スキーマ変更履歴（誰がいつ何を変更したか）を必ず残します。RBAC を使う場合はロールバインディングの変更監査も重要です。

CI/CD に統合し、スキーマ互換性チェック（バックワード/フォワード/フル）をパイプラインで強制することで、人手更新による破壊的変更を防ぎます。資格試験でも、互換性と権限を運用フローで強制する設計が問われます。

• TLS は最低限 1.2 以上、自己署名 CA の場合は全クライアントへ正しく配布
• 資格情報（パスワード/API Key）は Vault 等で管理し、ローテーション手順を整備
• 本番/検証/開発のレジストリを分離し、Subject 名や互換性ポリシーを環境で差別化
• メンテ時は書き込み権限を一時剥奪し、完了後に復旧（変更窓口を一本化）

試験対策チェックリスト（CCDAK / CCAAK）

用語と層の切り分け（REST 認証 vs Kafka ACL）を明確に。Serializer の schema.registry.* と Kafka 接続の sasl./ssl. は別系統という点は頻出です。

HTTP ステータスの意味、RBAC の粒度、_schemas の権限最小化など、選択肢のひっかけに注意。

• 401 は未認証、403 は認証済みだが権限不足
• basic.auth.credentials.source=USER_INFO と schema.registry.basic.auth.user.info=ユーザー:パスワード の組み合わせ
• mTLS 利用時の schema.registry.ssl.truststore/keystore の用途
• Schema Registry のサービスアカウントに _schemas: READ/WRITE/DESCRIBE
• RBAC の Subject 単位の権限制御（ResourceOwner 等）と Topic ACL は別物

問題で確認

よくある質問