> For the complete documentation index, see [llms.txt](https://docs.scepman.com/llms.txt). Markdown versions of documentation pages are available by appending `.md` to page URLs; this page is available as [Markdown](https://docs.scepman.com/ja/sono/security-faq.md). # セキュリティとプライバシー この章では、情報セキュリティ、プライバシー、品質保証に関するよくある質問の概要を説明します。 ## データ処理と権限 ### 1. SCEPman はどのデータを処理しますか？ SCEPman は、SCEP および EST プロトコルを使用して X.509 証明書を発行し、OCSP および CRL プロトコルを使用してそれらの証明書を検証します。各 **デバイス証明書** は一意のデバイス識別子を含める必要があります。さらに、 **ユーザー証明書**については、証明書の一部として次の値を構成することを推奨します: * ユーザー名 * メール アドレス * Microsoft Entra ID (Azure AD) UPN * デバイス識別子 SCEP、EST、OCSP および CRL は HTTP(S) に依存するため、つまり次のデータが SCEPman に表示されます: * クライアント IP アドレス + ポート * ユーザー エージェント（オペレーティング システムおよびブラウザー情報） Certificate Master は管理者アクティビティ（UPN）の監査証跡を保持します。 ### 2. SCEPman によって、または SCEPman の代わりに永続的に保存されるデータは何ですか。また、どのように保存されますか？ 1. 構成 * 構成データには常に SCEPman CA の公開鍵/秘密鍵ペアと証明書が含まれており、これらは Azure Key Vault に安全に保存されます。 * さらに、構成データには静的 SCEP チャレンジやパスワードなどのシークレットが含まれる場合があります。これらのパラメーターの目的については、SCEPman のドキュメントで説明されています。 * すべての構成パラメーターは、セキュリティを強化するために Azure Key Vault に保存できます。 2. 発行済み証明書 * 発行済みの証明書はすべて Azure Storage Account に保存されます - *秘密鍵を除く*. * 証明書の一部になりうるデータについては、 [質問 1](#id-1.-which-data-is-processed-by-scepman). * この動作は [無効化できます](/ja/scepman-gou-cheng/application-settings/basics.md#appconfig-enablecertificatestorage). * Certificate Master 経由で証明書を発行する場合、要求者（Microsoft Entra ID (Azure AD) UPN）が保存されます。 * Certificate Master 経由で証明書を失効する場合、証明書の失効状態と、それを失効したユーザーの ID（Microsoft Entra ID (Azure AD) UPN）が保存されます。 3. ログ記録 SCEPman のお客様の構成に応じて、ログ記録を有効にできます。お客様のログ詳細度設定に応じて、ログには SCEPman が処理するあらゆるデータが含まれる場合があります。ログの保存場所はお客様が構成します。 4. 外部 Log Analytics Workspace SCEPman は常に、 **機密ではない** かつ **個人情報ではない** 少量のデータをライセンス適用の目的で当社の Log Analytics Workspace (LAW) に送信します。このデータは * ライセンス目的に使用されます。 * 品質保証（たとえば、例外をグローバルに監視することで、一般的で広範囲な問題をすばやく把握でき、迅速にお客様へ対処を提供できるため、高額なサービス停止を防げます）。 既定では、SCEPman は **個人データを一切送信しません** 当社の LAW に。 ログ設定に応じて、デバッグ情報やその他の情報は glueckkanja-gab AG の LAW に転送されます。当社のサポート エンジニアは、トラブルシューティングの問い合わせを支援するために、 [有効化するよう](/ja/scepman-gou-cheng/application-settings/basics.md#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 #### scep\_challenge\_provider 1. scep\_challenge\_provider `:`\ \ `この権限により、SCEPman は証明書要求を Intune に転送し、その証明書要求が Intune から発行されたものであることを検証できます。後者により、追加のセキュリティ層が加わります。`Microsoft Graph 2. Directory.Read.All `:`\ \ `この権限により、SCEPman は Microsoft Entra ID (Azure AD) を参照して、ユーザー証明書またはデバイス証明書が承認済みのユーザーまたはデバイスに由来するかどうかを確認できます。`DeviceManagementManagedDevices.Read.All 3. Directory.Read.All `DeviceManagementConfiguration.Read.All` かつ `:`\ \ `これらの権限により、SCEPman は`EndpointList 失効機能 [を使用する際に、Intune 経由で発行済み証明書の一覧を要求します。](/ja/scepman-gou-cheng/application-settings/scep-endpoints/intune-validation.md#appconfig-intunevalidation-devicedirectory). 4. Directory.Read.All `IdentityRiskyUser.Read.All`:\ \ この権限により、SCEPman は自動的に [AAD User Risk が設定済みのしきい値を超えた場合にユーザー証明書を失効できます](/ja/scepman-gou-cheng/application-settings/scep-endpoints/intune-validation.md#appconfig-intunevalidation-userriskcheck). #### Jamf Pro 1. ユーザー、コンピューター、デバイスに対する読み取り権限\ \ これらの権限により、SCEPman はユーザー証明書またはデバイス証明書が承認済みのユーザーまたはデバイスに由来するかどうかを確認するために Jamf Pro を参照できます。 #### Certificate Master 1. Directory.Read.All `User.Read` （App Registration 経由）:\ \ この権限により、Certificate Master は誰が手動で証明書を要求または失効したかを判定します。 2. Directory.Read.All `DeviceManagementConfiguration.Read.All` かつ `:`\ \ `これらの権限により、SCEPman は` （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. Certificate Distribution Point (CDP) * 証明書失効リスト (CRL) は、このエンドポイントを介して利用できます。 * 〜から有効化できます [構成](/ja/scepman-gou-cheng/application-settings/crl.md). 6. Validation API * Certificate Master が証明書の自動失効状態を評価できるようにします。 7. SCEPman ホームページ * SCEPman の基本的なステータス情報を公開表示します（秘密情報はありません）。 * 読み取り専用。 * 〜から無効化できます [構成](/ja/scepman-gou-cheng/application-settings/basics.md#appconfig-anonymoushomepageaccess). 8. SCEPman probe エンドポイント * ヘルス チェック: 統合 App Service Health Check、Traffic Manager のプローブ、Application Gateway のプローブ。 #### Certificate Master 1. Certificate Master Web ポータル * サーバー証明書を手動で発行し、CSR に署名します。 * Certificate Master 経由で発行された証明書を手動で失効します。 * 手動で発行された証明書の一覧を表示します。 2. Certificate Master probe エンドポイント * ヘルス チェック: 統合 App Service Health Check ### 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. Certificate Distribution Point (CDP) * アクセストークンが必要です。 6. Validation 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) [ロールの割り当て](/ja/scepman-gou-cheng/rbac.md). 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. Certificate Distribution Point (CDP) * HTTP (TCP / 80) 6. Validation 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) ## ID ### 1. SCEPman を保護するために Conditional Access / ロールベースのアクセス制御は設定されていますか？ * はい。Microsoft Entra ID (Azure AD) の RBAC ポリシー一式を利用できます。 ### 2. アクセス資格情報は回復できますか？ 可能であれば、その方法は？ * ログイン資格情報: お客様テナントで構成された Microsoft Entra ID (Azure AD) ポリシーに依存します。 * 静的 SCEP チャレンジ: 承認済みユーザーはチャレンジにアクセスできます。 ## データ保護 ### 1. *保存時のデータ* は、どのようにして不正アクセスから保護されますか？ #### 構成データ * 構成データは Azure Key Vault（バージョン >= 1.7）に安全に保存できます。 * 構成データを Azure Key Vault に保存しないことを選択した場合は、AppService（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 Workspace に保存されます。 * 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 コンポーネント上に構築されているため、Microsoft Defender (MD) for Cloud のツール、たとえば MD for App Service、MD for Storage、または MD for Key Vault を利用できます。 #### 証明書の有効性 クラウド PKI として、SCEPman はデジタル証明書の発行と失効を担います。これらの証明書は秘密鍵と組み合わせることで、デバイスまたはユーザーを認証し、他のリソースへのアクセスを付与します。そのため、証明書の発行および失効プロセスのセキュリティは非常に重要な設計目標です。高いセキュリティ レベルを実現するには、高いユーザー利便性も必要です。複雑で不透明なプロセスは、攻撃面が広くなり、人為的ミスの可能性も高くなるためです。SCEPman は必要に応じて多くの構成オプションを提供しますが、可能な限り妥当で安全な既定値を使用するよう努めています。 そのため、秘密鍵が侵害された場合、SCEPman は対応する証明書をリアルタイムで失効できます。Intune および Jamf Pro 経由で登録された証明書については、SCEPman 固有ではない一般的な対策が攻撃に対して講じられ次第、自動的にこれを実行します。必要なのは、 [対応する Intune](/ja/scepman-gou-cheng/device-directories.md) または Jamf Pro オブジェクトを削除することだけです。 デバイス廃止プロセスに応じて、さらに次のように構成できます。 [ワイプがトリガーされたときに証明書を失効する](/ja/scepman-gou-cheng/application-settings/scep-endpoints/intune-validation.md#appconfigintunevalidationrevokecertificatesonwipe)、または [Intune が失効を要求したときに](/ja/scepman-gou-cheng/application-settings/scep-endpoints/intune-validation.md#appconfigintunevalidationdevicedirectory)、 [デバイス準拠状態](/ja/scepman-gou-cheng/application-settings/scep-endpoints/intune-validation.md#appconfigintunevalidationcompliancecheck) または [ユーザー リスク レベル](/ja/scepman-gou-cheng/application-settings/scep-endpoints/intune-validation.md#appconfigintunevalidationuserriskcheck)に応じて失効するようにできます。あるいは、Certificate Master コンポーネントを使って個々の証明書を手動で失効できます。 [手動で作成された証明書](/ja/zheng-ming-shu-guan-li/certificate-master.md) は常に手動での失効が必要です。 ### 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 Accounts #### 1. `Blob のパブリック アクセスを許可する` を無効にできますか？ *はい*、実際にはこれは新しい SCEPman インストールでは既定になっています。 ### App Services #### 2. TLS: `Client certificate mode` を `必須`? *いいえ*に設定できますか？ いいえ、これは SCEPman の機能を壊すためです。SCEPman はクライアント証明書を登録するため、クライアントはまだ認証に使うクライアント証明書を持っていません（鶏と卵の問題）。ただし、SCEP プロトコルは SCEP チャレンジを通じて独自の認証メカニズムを使用するため、これはセキュリティ上の問題ではありません。そのため、SCEPman は相互 TLS を強制するポリシーからの例外が必要です。Client certificate mode は `Client certificate mode` に設定する必要があります `無視` または `任意`. #### 3. `HTTP バージョン` を `2.0`? SCEPman は利用可能な HTTP バージョンのいずれでも動作するはずですが、現時点では既定の `HTTP 1.1` のみをサポートしています。主な理由はテスト不足です。 この設定を変更する際は - 自己責任で - SCEPman だけでなく、より新しい HTTP バージョンをサポートする必要があることに注意してください。さまざまな種類のクライアントも、その HTTP バージョンをサポートする必要があります。つまり、Windows、macOS、iOS、iPadOS に組み込まれた SCEP クライアント、IoT デバイス内のもの、同じプラットフォーム上の OCSP クライアント、さらにさまざまなベンダーの NAC です。 #### 4. `HTTPS Only` を有効にできますか？ *いいえ（SCEPman App Service では不可）*。これにより、多くの OCSP クライアントおよびベンダー製アプライアンスと組み合わせた SCEPman の OCSP 応答機能が壊れるためです。OCSP は、HTTPS よりも HTTP で提供されることの方が一般的なプロトコルです。その理由の 1 つは、証明書失効確認（CRL または OCSP のダウンロード）に TLS を使用すると、クライアントまたはアプライアンスが OCSP エンドポイントへの TLS 接続を確立できない鶏と卵の問題が発生する可能性があることです。サーバー証明書を OCSP で先に検証する必要があるためです。また、OCSP レスポンスは暗号学的に署名されているため、なりすましはできず、セキュリティ上の追加効果もあまりありません。そのため、SCEPman は TLS を強制するポリシーからの例外が必要です。 **注:** **`HTTPS Only`** SCEPman App Service では有効にできませんが、Certificate Master App Service では有効にする必要があります。 #### 5. 最小受信 TLS バージョンを 1.3 に設定できますか？ *いいえ* SCEPman App Service では、TLS 1.3 は再ネゴシエーションをサポートしないため、設定できません。つまり、一度接続が確立されると、サーバーはクライアントにクライアント証明書の提示を求めることができません。私たちは一部の状況（EST の簡易再登録）でクライアントが証明書で認証することを求めたいので、TLS を 1.3 に設定すると EST を使用した証明書更新ができなくなります。 さらに、すべての SCEP クライアントが TLS 1.3 をサポートしているわけではありません。重要な例として、Windows 8、10、11 に組み込まれた SCEP クライアントがあります。これは 2025-07 時点で TLS 1.3 をサポートしておらず（ [SCEP 登録中にクライアント側の](/ja/sono/troubleshooting/general.md#some-windows-machines-do-not-enroll-or-renew-certificates)). **注:** エラーが発生します）。Certificate Master App Service にアクセスするのはブラウザーのみであるため、Certificate Master では最小受信 TLS バージョンを 1.3 に設定することを推奨します。 ## コンプライアンス ### 1. glueckkanja は ISO 27001 認証を取得していますか？ はい。glueckkanja AG の情報セキュリティ マネジメント システム（ISMS）は、 **ISO/IEC 27001:2022**に準拠して認証されています。認証範囲は次のとおりです: * 製品開発 * マネージド サービス 現在の証明書は [こちら](https://www.glueckkanja.com/documents/general/gk-ISO27001Certificate-en.pdf). ### でご覧いただけます。 2\. glueckkanja は外部の専門家によってセキュリティ テストを受けていますか？ はい。2026 年に glueckkanja AG は、当社全体を対象とした Red Team 評価を実施するため、独立した専門のオフェンシブ セキュリティ企業に委託しました。 当社は、従来のペネトレーション テストよりも、この包括的なアプローチを意図的に選択しました。個々のシステムやエンドポイントを既知の脆弱性に照らして確認する代わりに、Red Team は内部攻撃者による現実的で高度なサイバー攻撃を当社の IT インフラストラクチャに対してシミュレートし、実際の攻撃者が行うように複数の手法を連鎖させました。 * この評価では次の点に重点を置きました: * 当社環境全体の完全な攻撃経路のマッピング、 * お客様環境への不正アクセスにつながる可能性のある経路の評価、 * サプライ チェーン攻撃を実行する可能性のある経路の評価。 すべての結果は対策提案とともに文書化され、ISO 27001 認証済みの情報セキュリティ マネジメント システムの一部として対応しています。 この Red Team 評価は毎年繰り返します。 ## GDPR とデータ所在地 ### 1. データはヨーロッパを離れますか？ * これは、SCEPman およびそのコンポーネントを展開する Azure データセンターの選択に依存します。 * すべてのコンポーネントを含む SCEPman の完全な展開を、ヨーロッパの Azure データセンターに行うことが可能です。 ### 2. SCEPman はどの 3rd-Party クラウド プロバイダーに依存し、なぜですか？ | 会社 | サービス | 連絡先 | 目的 | | -------------------------------------- | ---------------------------------- | --------------------------------------------------------------------------------------------- | ----------------------------------------------------------------------------------------- | | Microsoft Corporation | クラウド サービス（Azure） |

Building 3, Carmanhall Road Sandyford,
Industrial Estate 18, Dublin,
アイルランド

| 参照 [こちら](/ja/scepman-no/deployment-guides/enterprise-guide-1.md#overview-azure-resource). | | GitHub Inc（Microsoft Corporation の子会社） | git コード リポジトリ、統合、テスト、リリース自動化、ストレージ |

88 Colin P Kelly Jr St,

San Francisco,

CA 94107,

アメリカ合衆国

| コード リポジトリ、CI/CD パイプライン、バイナリ ストレージ | ## セキュア開発の実践 ### 1. SCEPman が安全なソフトウェアであることを何が保証していますか？ 当社のソフトウェア開発は [Microsoft Security Development Lifecycle](https://www.microsoft.com/en-us/securityengineering/sdl/)に基づいています。SDL の実践を採用することで、安全なコードとデプロイの作成に役立ちます。当社は製品開発について [ISO 27001 の情報セキュリティ認証を取得しています](#id-1.-is-glueckkanja-iso-27001-certified). ### 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)。私たちは、異なる専門性を持つ開発者チームにおける設計上の判断と潜在的な STRIDE 脅威について議論します。私たちの [CSOC ](https://www.glueckkanja.com/en/security/cloud-security-operations-center/)および PKI コンサルタント、サポートスタッフ。 #### カスタムコードよりもプラットフォームのセキュリティを優先する 可能な限り、私たちは車輪の再発明を避けるために、.NET や確立されたライブラリ、できればオープンソースの機能を使用します。たとえば、暗号データ標準を扱うために Legion of the Bouncy Castle C# を使用しています。また、暗号鍵の生成には Key Vault、Web サーバーのホスティングには App Services、ログ記録には 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 Services との統合により、Microsoft Defender for Cloud のサービス、たとえば Defender for App Service を活用できます。 #### 最小権限を徹底する Certificate Master の RBAC モデルにより、ユーザーには必要な権限だけを割り当てられます。 SCEPman は、必要な権限のみを持つ Managed Identities を使用しています [運用に必要な権限](#id-4.-which-tenant-permissions-does-the-admin-have-to-consent-to). #### 被害範囲を最小化する 攻撃が成功した場合の被害を最小限に抑えるよう努めています。たとえば、既定のインストールでは Key Vault の[ Soft Delete 機能と Purge Protection](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) を Certification Authority に対して使用します。Purge Protection 付きの Soft Delete により、悪意ある管理者や侵害された管理者アカウントでも CA の秘密鍵を削除できないことが保証されます。秘密鍵は数分で復元でき、通常業務を継続できます。さらに、Global Admin であっても 90 日間は完全削除できません。エクスポート不可の HSM バックの CA 鍵により、たとえ可能な限り高い権限を持つ攻撃者であっても CA 鍵を盗めないことが保証されます。 #### 攻撃対象領域を最小化する 私たちは、顧客の運用に必要なインターフェースだけを公開するようにしています。SCEP エンドポイントが未構成であれば、SCEP リクエストは処理すらされません。 使用することで [プライベート エンドポイント](/ja/azure-gou-cheng/private-endpoints.md)、SCEPman が依存する 2 つのサービス、Azure Key Vault と Azure Storage がインターネット経由で到達可能にならないようにしています。 #### 不正利用ケースを考慮する SCEPman が認可済みの証明書署名要求（CSR）を受け取った場合でも、いくつかの構成可能な制限が適用されます。たとえば、有効期間は [設定された最大有効期間](/ja/scepman-gou-cheng/application-settings/certificates.md#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. 定期的に侵入テストを実施していますか？ SCEPman に対する古典的な侵入テストという形では行っていません。代わりに、glueckkanja AG は独立した外部専門家による年次の Red Team アセスメントを受けており、これは古典的な侵入テストを上回るものです（参照 [glueckkanja は外部専門家によってセキュリティテストを受けていますか？](#id-2.-does-glueckkanja-have-its-security-tested-by-external-experts)). Secure Development Practices の一環として、私たちはツール（例：静的コード分析）を用いて、コードベースをスキャンし、SCEPman が公開するエンドポイントのセキュリティに影響し得る CVE やその他の一般的な悪用手法（サードパーティライブラリなどの依存関係を含む）を検出しています。各リリース前に、関連する指摘はすべて評価・是正し、SCEPman に既知の脆弱性が残らないようにしています。 私たちは自ら侵入テストを実施することも、サードパーティの「Penetration Test-as-a-Service」ツールを使用することもありません。前者については、利益相反が本質的に存在すると考えています。後者については、一般的な侵入テストサービスはしばしば公開されたエンドポイントを CVE やその他の既知の悪用手法と照合するだけなので、静的コード分析で既に行っているチェック以上の利点はないと考えています。 その代わりに、私たちは包括的なアプローチに依存しています。2026 年には、独立した Red Team が glueckkanja AG に対して、顧客環境への攻撃経路やサプライチェーン攻撃を明示的に含む、現実的で高度な攻撃をシミュレーションしました。孤立したエンドポイントをテストするのではなく、このアセスメントは組織全体にわたる完全な攻撃経路を評価するもので、これは顧客のセキュリティにとってはるかに重要だと考えています。このアセスメントは毎年繰り返しています。 ご自身で侵入テストを実施したい場合は、 [ご連絡ください](https://support.scepman.com/support/tickets/new?ticket_form=drop_a_question_%28scepman%29) そして要件をお知らせください。 --- # Agent Instructions This documentation is published with GitBook. GitBook is the documentation platform designed so that both humans and AI agents can read, navigate, and reason over technical content effectively. Learn more at gitbook.com. ## Querying This Documentation If you need additional information that is not directly available in this page, you can query the documentation by asking a question. Perform an HTTP GET request on the following URL with the `ask` and `goal` query parameters: ``` GET https://docs.scepman.com/ja/sono/security-faq.md?ask=&goal= ``` `ask` is the immediate question: it should be specific, self-contained, and written in natural language. `goal` is what the user is ultimately trying to achieve, the reason they need the answer. Sharing it helps GitBook give you a better, more relevant answer. A goal is most helpful when it describes the outcome the user wants rather than restating the question. For example, with `ask=how do I create an API token`, a goal like `automate deployments from our CI pipeline` lets GitBook tailor the answer to that use case. The response will contain a direct answer to the question and relevant excerpts and sources from the documentation. Use this mechanism when the answer is not explicitly present in the current page, you need clarification or additional context, or you want to retrieve related documentation sections.