# セキュリティとプライバシー ## データ処理と権限 ### 1. SCEPman によって処理されるデータは何ですか？ SCEPman は、発行には SCEP および EST プロトコルを、これらの証明書の検証には OCSP および CRL プロトコルを使用して X.509 証明書を処理します。各 **デバイス証明書** には一意のデバイス識別子が含まれている必要があります。さらに、 **ユーザー証明書**については、証明書の一部として以下の値を設定することを推奨します。 * ユーザー名 * メールアドレス * Microsoft Entra ID (Azure AD) UPN * デバイス識別子 SCEP、EST、OCSP、および CRL は HTTP(S) に依存するため、SCEPman からは以下のデータが見えます。 * クライアント IP アドレス + ポート * ユーザーエージェント（OS とブラウザー情報） Certificate Master は、管理者のアクティビティ（UPN）について監査証跡を保持します。 ### 2. SCEPman によって、または SCEPman を代行して永続的に保存されるデータは何ですか？ また、どのように保存されますか？ 1. Configuration * 構成データには常に SCEPman CA の公開鍵/秘密鍵ペアと証明書が含まれ、これは Azure Key Vault に安全に保存されます。 * さらに、構成データには静的な SCEP チャレンジやパスワードなどのシークレットが含まれる場合があります。これらのパラメーターの目的は SCEPman のドキュメントで説明されています。 * すべての構成パラメーターは、セキュリティ強化のため Azure Key Vault に保存できます。 2. 発行済み証明書 * 発行済みのすべての証明書は Azure Storage Account に保存されます - *秘密鍵を除く*. * 証明書の一部になり得るデータについては、 [質問 1](#id-1.-which-data-is-processed-by-scepman). * この動作は [無効化できます](https://docs.scepman.com/ja/scepman-gou-cheng/application-settings/basics#appconfig-enablecertificatestorage). * Certificate Master を通じて証明書を発行する際、要求者（Microsoft Entra ID (Azure AD) UPN）が保存されます。 * Certificate Master を通じて証明書を失効する際、証明書の失効状態と、それを失効したユーザーの識別情報（Microsoft Entra ID (Azure AD) UPN）が保存されます。 3. ログ お客様による SCEPman の構成に基づき、ログ記録を有効にできます。お客様のログ詳細度の設定に応じて、ログには SCEPman が処理するあらゆるデータが含まれる場合があります。ログの保存場所はお客様が構成します。 4. 外部 Log Analytics Workspace SCEPman は、ライセンス目的のために、常に限定的な量の **シークレットでない** および **個人情報でない** データを当社の Log Analytics Workspace (LAW) に送信します。このデータは * ライセンス目的、 * 品質保証（例：例外をグローバルに監視することで、一般的かつ広範な問題を迅速に把握し、顧客に素早く対処できるようにすることで、高額なサービス停止を防ぎます）に使用されます。 既定では、SCEPman は **個人データを送信しません** 当社の LAW に。 ログ設定に応じて、デバッグ情報やその他の情報が glueckkanja-gab AG の LAW に転送されます。サポートエンジニアは、トラブルシューティングの支援のために、顧客管理者に [有効化](https://docs.scepman.com/ja/scepman-gou-cheng/application-settings/basics#appconfig-remotedebug) を依頼する場合があります。そのような場合、証明書要求に関する情報が当社の LAW アカウントに送信されることがあり、（証明書の一部として何を含めるかはお客様が決定します）以下のような個人データが含まれる可能性があります。 * ユーザー名 * メールアドレス * Microsoft Entra ID (Azure AD) UPN * デバイス識別子 当社は定期的に **すべての** 記録データを削除します。間隔は * 30日 ### 3. SCEPman はどこで（地理的に）データを処理および保存しますか？ 設計上、SCEPman は Azure App（ソリューションテンプレートベース）として実現されており、つまりお客様の Azure テナントに展開されます。したがって、ホスティング先データセンターの地理的な場所の選択を含むデータ主権は、お客様の管理と選好の範囲内です。 #### 外部 Log Analytics Workspace 当社が（既定で **個人情報でない** および **シークレットでない**）ライセンス強制の目的でテレメトリ情報を収集するために利用する外部 LAW は、 **Azure の西ヨーロッパ** データセンターにあります。 ### 4. 管理者はどのテナント権限への同意が必要ですか？ SCEPman は Managed Identities を活用して、Azure テナント内に安全な権限モデルを実装します。 #### Intune 1. Intune `scep_challenge_provider`:\ \ この権限により、SCEPman は証明書要求を Intune に転送し、その要求が Intune 由来であることを検証できます。これにより、追加のセキュリティ層が提供されます。 2. Microsoft Graph `Directory.Read.All`:\ \ この権限により、SCEPman は Microsoft Entra ID (Azure AD) を参照して、ユーザー証明書またはデバイス証明書が承認済みのユーザーまたはデバイスに由来するかどうかを確認できます。 3. Microsoft Graph `DeviceManagementManagedDevices.Read.All` および `DeviceManagementConfiguration.Read.All`:\ \ これらの権限により、SCEPman は [EndpointList 失効機能](https://docs.scepman.com/ja/scepman-gou-cheng/application-settings/scep-endpoints/intune-validation#appconfig-intunevalidation-devicedirectory). 4. Microsoft Graph `IdentityRiskyUser.Read.All`:\ \ この権限により、SCEPman は [AAD ユーザーリスクが設定された閾値を超えた場合にユーザー証明書を自動的に失効できます](https://docs.scepman.com/ja/scepman-gou-cheng/application-settings/scep-endpoints/intune-validation#appconfig-intunevalidation-userriskcheck). #### Jamf Pro 1. ユーザー、コンピューター、およびデバイスに対する読み取り権限\ \ これらの権限により、SCEPman は Jamf Pro を参照して、ユーザー証明書またはデバイス証明書が承認済みのユーザーまたはデバイスに由来するかどうかを確認できます。 #### Certificate Master 1. Microsoft Graph `User.Read` （App Registration 経由）:\ \ この権限により、Certificate Master は、誰が手動で証明書を要求または失効したかを判定します。 2. Micrsoft Graph `DeviceManagementManagedDevices.Read.All` および `DeviceManagementConfiguration.Read.All` （Managed Identity として）:\ \ これらの権限により、Certificate Master は Intune 経由で発行済み証明書の一覧を要求します。管理者はこれらの証明書を確認し、手動で失効できます。 ### 5. SCEPman はどの外部アクセス可能なエンドポイントを公開しますか？ #### **SCEPman Core Service** 1. SCEP エンドポイント * SCEP リクエストのために呼び出されます。 * 構成に基づき、SCEPman は Intune、Jamf Pro、DC、一般的なその他の MDM 向けに複数の SCEP エンドポイントを公開する場合があります。 2. Enrollment REST API * Certificate Master が SCEPman のコアサービスから証明書を要求できるようにします。 * カスタムアプリケーションが SCEPman のコアサービスから証明書を要求できるようにします。 3. EST エンドポイント * EST の簡易再登録要求に対して呼び出されます。構成により有効化できます。 * EST の簡易登録要求に対して呼び出されます。 4. OCSP エンドポイント * OCSP リクエストに対して呼び出されます。 5. 証明書配布ポイント (CDP) * このエンドポイントを通じて証明書失効リスト（CRL）が公開されます。 * で有効化できます [構成](https://docs.scepman.com/ja/scepman-gou-cheng/application-settings/crl). 6. 検証 API * Certificate Master が証明書の自動失効状態を評価できるようにします。 7. SCEPman ホームページ * SCEPman の基本ステータス情報を公開表示します（シークレットなし）。 * 読み取り専用。 * で無効化できます [構成](https://docs.scepman.com/ja/scepman-gou-cheng/application-settings/basics#appconfig-anonymoushomepageaccess). 8. SCEPman probe エンドポイント * ヘルスチェック: 統合 App Service ヘルスチェック、Traffic Manager のプロービング、Application Gateway のプロービング。 #### Certificate Master 1. Certificate Master Web ポータル * サーバー証明書を手動で発行し、CSR に署名します。 * Certificate Master で発行された証明書を手動で失効します。 * 手動発行された証明書の一覧を表示します。 2. Certificate Master probe エンドポイント * ヘルスチェック: 統合 App Service ヘルスチェック ### 6. 5 のエンドポイントはどのように保護されていますか？ #### SCEPman Core Service 1. SCEP エンドポイント * Intune: Intune Challenge API（[Microsoft Docs](https://docs.microsoft.com/en-us/mem/intune/protect/scep-libraries-apis)) * Jamf Pro、DC、一般的なその他の MDM: 静的 SCEP チャレンジで保護されます。お客様が構成可能です。Azure Key Vault に保存される場合があります。 2. Enrollment REST API * Microsoft Entra ID (Azure AD) 統合認証。 3. EST エンドポイント * 簡易再登録: 証明書ベースの認証。 * 簡易登録: Microsoft Entra ID (Azure AD) 統合認証。 4. OCSP エンドポイント * 保護は不要です。 5. 証明書配布ポイント (CDP) * アクセス トークンが必要です。 6. 検証 API * Microsoft Entra ID (Azure AD) 統合認証。 7. SCEPman ホームページ * 保護はありませんが、無効化できます。 8. SCEPman probe エンドポイント * 保護はありません。 #### Certificate Master 1. Certificate Master Web ポータル * Microsoft Entra ID (Azure AD) 統合認証。 * Microsoft Entra ID (Azure AD) [ロール割り当て](https://docs.scepman.com/ja/scepman-gou-cheng/rbac). 2. Certificate Master probe エンドポイント * 保護はありません。 ### 7. 質問 6 のエンドポイントで使用されるポートとプロトコルは何ですか？ **SCEPman Core Service** 1. SCEP エンドポイント * Intune: HTTPS (TCP / 443) * Jamf Pro、DC、一般的なその他の MDM: HTTPS (TCP / 443) 2. Enrollment REST API * HTTPS (TCP / 443) 3. EST エンドポイント * HTTPS (TCP / 443) 4. OCSP エンドポイント * HTTP (TCP / 80) 5. 証明書配布ポイント (CDP) * HTTP (TCP / 80) 6. 検証 API * 外部サービスでは使用されません。 7. SCEPman ホームページ * HTTPS (TCP / 443) 8. SCEPman probe エンドポイント * HTTPS (TCP / 443) #### Certificate Master 1. Certificate Master Web ポータル * HTTPS (TCP / 443) 2. Certificate Master probe エンドポイント * HTTPS (TCP / 443) ## アイデンティティ ### 1. SCEPman を保護するために条件付きアクセス / ロールベースのアクセス制御は導入されていますか？ * はい。Microsoft Entra ID (Azure AD) の RBAC ポリシー一式を活用できます。 ### 2. アクセス資格情報は復旧できますか？ できる場合、その方法は？ * ログイン資格情報: お客様テナントで構成された Microsoft Entra ID (Azure AD) ポリシーによります。 * 静的 SCEP チャレンジ: 承認されたユーザーはチャレンジにアクセスできます。 ## データ保護 ### 1. *保存データ* はどのように不正アクセスから保護されていますか？ #### 構成データ * 構成データは Azure Key Vault（バージョン >= 1.7）に安全に保存できます。 * 構成データを Azure Key Vault に保存しない場合は、App Service 上に保存されます（BitLocker 暗号化） * 任意の構成データ（Azure Key Vault、App Services）には、関連する Azure 権限を持つ承認済みユーザーのみがアクセスできます。 #### 暗号鍵 * CA の秘密鍵は Azure Key Vault に安全に保存されます（[FIPS 140 検証済み HSM](https://learn.microsoft.com/en-us/azure/key-vault/keys/about-keys#compliance) が既定）。 * 秘密鍵は読み取りもエクスポートもできません。 * 秘密鍵は不正な管理者による削除から保護されます（[削除保護と論理削除](https://learn.microsoft.com/en-us/azure/key-vault/general/soft-delete-overview) が既定で有効）。 * Azure Key Vault はプライベート エンドポイントを使用し、SCEPman からのみアクセスできます（バージョン 2.8 以降の SCEPman インストールの既定）。 #### 証明書データベース * データベースは Azure Storage Account の Table サービスを使用します。したがって、保護は Azure に組み込まれたメカニズムに依存します。 * 特に、Azure はデータへのアクセス権限を管理するためにロールベースのアクセスを採用しています。 * Azure Storage はデータベース暗号化を使用し、カスタマー管理キーをサポートします。 * Azure Storage Account はプライベート エンドポイントを使用し、SCEPman からのみアクセスできます（バージョン 2.8 以降の SCEPman インストールの既定）。 #### ログ * ログは Log Analytics ワークスペースに保存されます。 * Log Analytics はデータベース暗号化を使用し、カスタマー管理キーをサポートします。 ### 2. *転送中データ* はどのように不正アクセスから保護されていますか？ * SCEP: * 既定で TLS を使用します（最低 TLS 1.2 - Microsoft のポリシーが適用されます）。 * SCEP 要求は CA 証明書宛てに暗号化され、クライアント証明書で署名されます。 * SCEP 応答はクライアント証明書宛てに暗号化され、CA 証明書で署名されます。 * OCSP: * OCSP 要求は、鶏卵問題を避けるため暗号化しないでください。 * OCSP 応答は CA 証明書で署名されます。 * Enrollment REST API および EST: * TLS を強制します（最低 TLS 1.2 - Microsoft のポリシーが適用されます）。 * Certificate Master Web ポータル: * TLS を強制します（最低 TLS 1.2 - Microsoft のポリシーが適用されます）。 * SCEPman Azure コンポーネント間の通信: * TLS（最低 TLS 1.2 - Microsoft のポリシーが適用されます）。 ## 設計によるセキュリティ ### 1. SCEPman は多層防御戦略を採用していますか？ #### Azure コンポーネント SCEPman の設計哲学は、外部インターフェースを必要最小限に減らすことで、外部のセキュリティ脅威への露出を最小化するという方針に従っています。さらに、以下の技術を使用して、さまざまな層における内部および外部の脅威を識別・軽減しています。 * Key Vault * App Insights * Intune デバイス登録検証 * Microsoft Entra ID (Azure AD) デバイスチェック * プライベート エンドポイント SCEPman は Azure コンポーネント上に構築されているため、MD for App Service、MD for Storage、MD for Key Vault などの Microsoft Defender for Cloud ツールを利用できます。 #### 証明書の有効性 クラウド PKI として、SCEPman はデジタル証明書の発行と失効を担当します。これらの証明書とその秘密鍵はデバイスまたはユーザーを認証し、他のリソースへのアクセスを許可します。したがって、証明書の発行および失効プロセスのセキュリティは非常に重要な設計目標です。セキュリティレベルが高いほど、ユーザーの利便性も高い必要があります。複雑で不透明なプロセスは攻撃対象領域が広く、人的エラーの可能性も高くなるためです。SCEPman は必要に応じて多くの構成オプションを提供しますが、可能な限り合理的で安全な既定値を使用するよう努めています。 したがって、秘密鍵が侵害された場合、SCEPman は対応する証明書をリアルタイムで失効できます。Intune および Jamf Pro 経由で登録された証明書については、SCEPman 固有ではない一般的な対策が攻撃に対して講じられた時点で、SCEPman が自動的にこれを行います。必要なのは [対応する Intune を削除する](https://docs.scepman.com/ja/scepman-gou-cheng/device-directories) か Jamf Pro オブジェクトを削除することだけです。 デバイス廃止プロセスに応じて、さらに以下を構成できます。 [ワイプがトリガーされたときに証明書を失効する](https://docs.scepman.com/ja/scepman-gou-cheng/application-settings/scep-endpoints/intune-validation#appconfigintunevalidationrevokecertificatesonwipe)、 [Intune が失効を要求したとき](https://docs.scepman.com/ja/scepman-gou-cheng/application-settings/scep-endpoints/intune-validation#appconfigintunevalidationdevicedirectory)、 [デバイス準拠](https://docs.scepman.com/ja/scepman-gou-cheng/application-settings/scep-endpoints/intune-validation#appconfigintunevalidationcompliancecheck) または [ユーザー リスク レベル](https://docs.scepman.com/ja/scepman-gou-cheng/application-settings/scep-endpoints/intune-validation#appconfigintunevalidationuserriskcheck)に応じて、または Certificate Master コンポーネントを通じて個別の証明書を手動で失効できます。 [手動で作成された証明書は](https://docs.scepman.com/ja/zheng-ming-shu-guan-li/certificate-master) 常に手動失効が必要です。 ### 2. SCEPman の設計に使用された技術、スタック、プラットフォームは何ですか？ * `C#` * `ASP.NET Core MVC` * `Bouncy Castle Crypto API` * `Azure（App Service、Key Vault、Storage Account、Log Analytics）` ### 3. SCEPman はどの暗号アルゴリズムと鍵サイズをサポートしていますか？ 発行済み証明書の鍵については、CSR メソッドを使用する場合、Certificate Master に制限はありません。フォームベースの証明書では、RSA の 2048 ビットまたは 4096 ビットがサポートされるアルゴリズムと鍵サイズです。 SCEP 登録証明書については、Intune はすべてのプラットフォームで最大 RSA 4096 ビット鍵をサポートしており、SCEPman もそれをサポートしています。プラットフォーム KSP（TPM）を使用する場合、Windows がサポートするのは最大 RSA 2048 ビット鍵です。静的 SCEP エンドポイントを使用する場合、一般的なすべてのアルゴリズムと鍵サイズがサポートされます（特に [C# 用の Bouncy Castle 暗号ライブラリがサポートするもの）](https://www.bouncycastle.org/csharp/)). CA 鍵については、SCEPman は RSA のみをサポートします。RSA 4096 ビットが既定の鍵サイズです。4096 ビットは現在、Azure Key Vault がサポートする最大値です。中間 CA 証明書を使用する場合は、Key Vault がサポートする任意の鍵サイズも使用できますが、RSA 鍵である必要があります。 SCEP を必要としないシナリオでは、ECC CA を作成でき、次の楕円曲線がサポートされます: P-256、secp256k1/P-256K、P-384、P-521。 ### 4. SCEPman によって作成される CA は一意ですか？ はい 詳細: * SCEPman は、テナント内の Azure Key Vault で Root CA の秘密鍵と公開鍵のペアを生成します。したがって、Root CA はお客様専用の SCEPman インスタンスに固有であり、CA、その証明書、および対応する秘密鍵を完全に制御できます。 * この CA へのアクセスは、必要に応じて変更できる Key Vault アクセス ポリシーによって制御されます。既定では、お客様自身の SCEPman インスタンスのみが証明書を使用でき、他の誰も（管理者であっても）使用できませんが、サブスクリプション管理者は追加の権限を付与できます。 * したがって、他の SCEPman 顧客は、どのように SCEPman を構成しても、お客様の VPN に接続できません。同じ組織名を選択しても、彼らは独自の鍵ペアを持つため、お客様の VPN Gateway が信頼しない別の CA 証明書を使用することになります。 ## Azure CIS このセクションでは、Azure 環境向けのサイバー防御ポリシーを定義する際、または [CIS Microsoft Azure Foundations Benchmark](https://www.cisecurity.org/benchmark/azure/). ### Storage Account #### 1. `Blob のパブリック アクセスを許可` を無効化できますか？ *はい*実際、これは新しい SCEPman インストールでは既定値です。 ### App Services #### 2. TLS: `クライアント証明書モード` を `Require`? *いいえ*に設定できますか？ これは SCEPman の機能を壊してしまうためです。これは、SCEPman がクライアント証明書を登録するため、クライアント側にはまだ認証に使用できるクライアント証明書がないためです（鶏卵問題）。ただし、SCEP プロトコルは SCEP チャレンジを通じた独自の認証メカニズムを使用するため、セキュリティ上の問題ではありません。したがって、SCEPman は相互 TLS を強制するポリシーからの例外が必要です。 `クライアント証明書モード` は `Ignore` または `任意`. #### 3. `HTTP バージョン` を `2.0`? SCEPman は利用可能な HTTP バージョンのいずれでも動作すべきですが、現時点では既定の `HTTP 1.1` のみをサポートしています。主にテスト不足のためです。 この設定を変更する場合は自己責任でお願いします。SCEPman だけでなく、新しい HTTP バージョンをサポートする必要があることに注意してください。さまざまな種類のクライアントもその HTTP バージョンをサポートする必要があります。つまり、Windows、macOS、iOS、iPadOS の OS 統合 SCEP クライアント、IoT デバイス内のクライアント、同じプラットフォームの OCSP クライアント、さらにさまざまなベンダーの NAC も対象です。 #### 4. `HTTPS のみ` を有効にできますか？ *いいえ（SCEPman App Service では不可）*。OCSP は HTTPS より HTTP でより一般的に提供されるプロトコルだからです。その理由の一つは、証明書失効確認（CRL または OCSP のダウンロード）に TLS を使うと、クライアントまたはアプライアンスが OCSP エンドポイントへの TLS 接続を確立できないという鶏卵問題が発生する可能性があるためです。サーバー証明書はまず OCSP で検証する必要があるからです。また、OCSP 応答は暗号学的に署名されているため、なりすましはできず、セキュリティ上の上積みもあまりありません。したがって、SCEPman は TLS を強制するポリシーからの例外が必要です。 **注意:** **`HTTPS のみ`** SCEPman App Service では有効にできませんが、Certificate Master App Service では有効にする必要があります。 #### 5. 最小受信 TLS バージョンを 1.3 に設定できますか？ *いいえ* TLS 1.3 は再ネゴシエーションをサポートしないため、SCEPman App Service ではできません。これは、一度接続が確立されると、サーバーがクライアントにクライアント証明書の提示を要求できないことを意味します。私たちは、特定の状況（EST の簡易再登録）でクライアントが証明書で認証することを望んでいるため、TLS を 1.3 に設定すると EST を使用して証明書を更新できなくなります。 さらに、すべての SCEP クライアントが TLS 1.3 をサポートしているわけではありません。重要な例として、Windows 8、10、11 に統合された SCEP クライアントがあり、2025-07 時点では TLS 1.3 をサポートしていません（クライアント側で [SCEP 登録中にエラーが発生します](https://docs.scepman.com/ja/troubleshooting/general#some-windows-machines-do-not-enroll-or-renew-certificates)). **注意:** Certificate Master App Service にアクセスするのはブラウザーのみなので、Certificate Master では最小受信 TLS バージョンを 1.3 に設定することを推奨します。 ## GDPR とデータ所在地 ### 1. データはヨーロッパの外に出ますか？ * これは、SCEPman とそのコンポーネントを展開する Azure データセンターの選択をお客様がどう決めるかによります。 * すべてのコンポーネントを含む SCEPman の完全展開を、ヨーロッパの Azure データセンターに行うことが可能です。 ### 2. SCEPman はどのサードパーティのクラウドプロバイダーに依存しており、なぜですか？ | 会社 | サービス | 連絡先 | 目的 | | -------------------------------------- | --------------------------------- | ----------------------------------------------------------------------------------------- | -------------------------------------------------------------------------------------------------------------------- | | Microsoft Corporation | クラウド サービス（Azure） |

Building 3, Carmanhall Road Sandyford,
Industrial Estate 18, Dublin,
Ireland

| 参照 [こちら](https://docs.scepman.com/ja/scepman-zhan-kai/deployment-guides/enterprise-guide-1#overview-azure-resource). | | GitHub Inc（Microsoft Corporation の子会社） | git コード リポジトリ、統合、テストおよびリリース自動化、保存 |

88 Colin P Kelly Jr St,

San Francisco,

CA 94107,

United States

| コード リポジトリ、CI/CD パイプライン、バイナリ保存 | ## 安全な開発プラクティス ### 1. SCEPman が安全なソフトウェアであることを何が保証していますか？ 当社のソフトウェア開発は [Microsoft Security Development Lifecycle](https://www.microsoft.com/en-us/securityengineering/sdl/)に基づいています。SDL の実践を採用することで、安全なコードとデプロイの作成に役立てています。 [製品開発について ISO 27001 の情報セキュリティ認証を取得しています。](https://www.glueckkanja.com/documents/general/gk-ISO27001Certificate-en.pdf) ### 2. 一般的な安全な設計プラクティスをどのように実装していますか？ 以下のように [SDL が推奨する安全な設計プラクティス](https://www.microsoft.com/en-us/securityengineering/sdl/practices/secure-by-design): #### チームとして設計と脅威モデルを行う 当社の脅威モデリングの実践は [Tufts Security and Privacy Lab の推奨](https://tsp.cs.tufts.edu/tmnt/threatmodeling.html)に基づいています。開発者、 [CSOC ](https://www.glueckkanja.com/en/security/cloud-security-operations-center/)および PKI コンサルタント、サポート要員からなる異種混成チームで、設計上の決定と潜在的な STRIDE 脅威について議論します。 #### プラットフォームのセキュリティをカスタムコードより優先する 可能な限り、車輪の再発明を避けるため、.NET や確立されたライブラリ、できればオープンソースの機能を使用します。たとえば、暗号データ標準を扱うために Legion of the Bouncy Castle C# を使用しています。また、暗号鍵の生成には Key Vault、Web サーバーホスティングには App Service、ログには Azure Monitor、データベースエンジンには Azure Storage などの Azure サービスも利用しています。 #### 安全な構成を既定にする 人的エラーの可能性を最小限に抑えるため、既定値を使用した場合に安全な構成になるよう製品を設計しています。たとえば、当社の [ARM テンプレート](https://github.com/scepman/install) および [Terraform プロバイダー ](https://registry.terraform.io/modules/scepman/scepman/)は、4096 ビットの HSM バック RSA 鍵を使用するように構成設定を行い、Intune SCEP と Certificate Master 以外のすべての登録エンドポイントを無効化します（これらには明示的に権限を割り当てる必要があります）。 #### クライアントからのデータを決して信用しない PKI ソフトウェアとして、どのデータを信頼するかの判断は、あらゆる決定の核心にあります。結局のところ、証明書とその登録プロトコルの目的は、どのデータを信頼するかを決定することです。 #### 侵害を前提とする Azure Monitor に基づく当社のログ記録により、SCEPman の動作を監視できます。Sentinel のような SIEM システムと容易に統合でき、たとえば無許可で証明書の登録に成功した攻撃者を検出できます。Azure サービスとの統合により、Defender for App Service などの Microsoft Defender for Cloud サービスを活用できます。 #### 最小権限を徹底する Certificate Master の RBAC モデルにより、ユーザーに本当に必要な権限のみを割り当てられます。 SCEPman は Managed Identities を使用しており、その権限は [運用に必要なものだけです](#id-4.-which-tenant-permissions-does-the-admin-have-to-consent-to). #### 爆発範囲を最小化する 成功した攻撃があっても可能な被害を最小限に抑えるよう努めています。たとえば、既定のインストールでは Key Vault の[ 削除保護付き論理削除機能](https://learn.microsoft.com/en-us/azure/key-vault/general/soft-delete-overview) を [エクスポート不可の HSM バック秘密鍵](https://learn.microsoft.com/en-us/azure/key-vault/keys/about-keys#hsm-protected-keys) とともに、認証局向けに有効にします。削除保護付き論理削除により、不正な管理者や侵害された管理者アカウントが CA の秘密鍵を削除できないことが保証されます。通常運用を継続するために数分で復元でき、グローバル管理者であっても 90 日間は完全削除できません。エクスポート不可の HSM バック CA 鍵により、可能な限り高い権限を持つ攻撃者であっても CA 鍵を盗めないことが保証されます。 #### 攻撃対象領域を最小化する お客様の運用に必要なインターフェースのみを公開するようにしています。SCEP エンドポイントが未構成の場合、SCEP リクエストは処理すらされません。 を使用することで [プライベート エンドポイント](https://docs.scepman.com/ja/azure-gou-cheng/private-endpoints)、SCEPman が依存する Azure Key Vault と Azure Storage の 2 つのサービスがインターネット経由で到達不能であることを保証します。 #### 悪用ケースを考慮する SCEPman が承認済みの証明書署名要求（CSR）を受け取った場合でも、いくつかの構成可能な制限が適用されます。たとえば、有効期間は [設定された最大有効期間](https://docs.scepman.com/ja/scepman-gou-cheng/application-settings/certificates#appconfig-validityperioddays)を決して超えられません。要求されていてもです。 #### セキュリティイベントを監視し、アラートを出す SCEPman がセキュリティイベントを検出すると、それらは Warning または Error としてログに記録されます。Azure Monitor と Azure Event Hub との統合により、 [アラートを構成](https://learn.microsoft.com/en-us/azure/azure-monitor/alerts/alerts-overview) したり、SIEM でこれらのセキュリティイベントを分析したりすることが容易になります。 ### 3. 自社の開発環境をどのように保護していますか？ CSOC サービスとセキュリティコンサルティングも提供する企業の一員として、当社はデバイス、プロセス、ユーザー意識に対して高いセキュリティ基準を設けています。当社は Microsoft MISA の一員であり、ISO 27001 認証を取得し、セキュリティ分野の提供で Microsoft Partner of the Year にも選ばれています。 当社のソースリポジトリには Branch Protection ルールがあり、各開発者アカウントにはリポジトリおよびデプロイ パイプラインに対して必要最小限の権限のみを割り当てています。侵害されたアカウントによる攻撃対象領域を減らすため、可能な限りテストとデプロイを自動化しています。 ### 4. SCEPman はバグバウンティプログラムの対象ですか？ いいえ。 ### 5. どのような QA 対策がありますか？ * SCEPman は内部、ベータ、プロダクションの各チャネルで提供しています * 各本番リリースは、CI プロセスの一環として関連する QA 関門を通過しながら、まず内部チャネルとベータチャネルを通過する必要があります * 単体テスト * 相互レビュー * 統合テスト * ストレステスト * 経験ベースのテスト * サードパーティのコード分析（例: Sonar、Dependabot など） ### 6. 定期的に侵入テストを実施していますか？ いいえ。 安全な開発プラクティスの一環として、当社はコードベースを CVE やその他の一般的なエクスプロイト（サードパーティライブラリなどの依存関係を含む）についてスキャンするツール（例: 静的コード解析）を使用し、SCEPman が公開するエンドポイントのセキュリティに影響を与え得るものを検出しています。各リリース前に、関連する指摘は評価され、修正され、SCEPman が既知の脆弱性を持たないことを確認します。当社は自ら侵入テストを実施しておらず、またサードパーティの「Penetration Test-as-a-Service」ツールも使用していません。前者については、利益相反が本質的にあると考えています。後者については、一般的な侵入テストサービスは公開エンドポイントを CVE やその他の既知のエクスプロイトに対してチェックするだけであることが多く、静的コード解析ですでに行っているチェックに追加の価値はないと考えています。ご自身で侵入テストを実施したい場合は、 [お問い合わせください](https://support.scepman.com/support/tickets/new?ticket_form=drop_a_question_%28scepman%29) そして要件をお知らせください。