> 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 プロトコルを、証明書の検証に OCSP および CRL プロトコルを使用して X.509 証明書を処理します。各 **デバイス証明書** には、一意のデバイス識別子が含まれている必要があります。さらに、 **ユーザー証明書**については、証明書の一部として次の値を設定することを推奨します。
* ユーザー名
* メールアドレス
* 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 を介して証明書を失効すると、証明書の失効状態と、それを失効させたユーザーの識別情報（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 の West Europe** データセンターにあります。
### 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 失効機能](/ja/scepman-gou-cheng/application-settings/scep-endpoints/intune-validation.md#appconfig-intunevalidation-devicedirectory).
4. Microsoft Graph `IdentityRiskyUser.Read.All`:\
\
この権限により、SCEPman は [AAD ユーザー リスクが構成されたしきい値を超えた場合にユーザー証明書を自動的に失効できます](/ja/scepman-gou-cheng/application-settings/scep-endpoints/intune-validation.md#appconfig-intunevalidation-userriskcheck).
#### Jamf Pro
1. ユーザー、コンピューター、デバイスに対する読み取り権限\
\
これらの権限により、SCEPman は証明書が承認済みのユーザーまたはデバイスに由来するかを確認するために Jamf Pro を参照できます。
#### Certificate Master
1. Microsoft Graph `User.Read` （App Registration 経由）:\
\
この権限により、Certificate Master は、証明書を手動で要求または失効するのが誰かを判定します。
2. Microsoft Graph `DeviceManagementManagedDevices.Read.All` かつ `DeviceManagementConfiguration.Read.All` （Managed Identity として）:\
\
これらの権限により、Certificate Master は Intune 経由で発行済み証明書の一覧を要求します。管理者はこれらの証明書を確認し、手動で失効できます。
### 5. SCEPman はどの外部アクセス可能なエンドポイントを公開しますか？
#### **SCEPman コア サービス**
1. SCEP エンドポイント
* SCEP リクエストに対して呼び出されます。
* 構成に応じて、SCEPman は Intune、Jamf Pro、DCs、汎用のその他 MDM 向けに複数の SCEP エンドポイントを公開できます。
2. Enrollment REST API
* Certificate Master が SCEPman のコア サービスから証明書を要求できるようにします。
* カスタム アプリケーションが SCEPman のコア サービスから証明書を要求できるようにします。
3. EST エンドポイント
* EST の simple re-enroll 要求に対して呼び出されます。構成で有効にできます。
* EST の simple enroll 要求に対して呼び出されます。
4. OCSP エンドポイント
* OCSP リクエストに対して呼び出されます。
5. Certificate Distribution Point (CDP)
* Certificate Revocation List (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 プローブ エンドポイント
* ヘルス チェック: 統合 App Service Health Check、Traffic Manager プロービング、Application Gateway プロービング。
#### Certificate Master
1. Certificate Master Web ポータル
* サーバー証明書を手動で発行し、CSR に署名します。
* Certificate Master を通じて発行された証明書を手動で失効します。
* 手動で発行された証明書の一覧を表示します。
2. Certificate Master プローブ エンドポイント
* ヘルス チェック: 統合 App Service Health Check
### 6. 5 のエンドポイントはどのように保護されていますか？
#### SCEPman コア サービス
1. SCEP エンドポイント
* Intune: Intune Challenge API（[Microsoft Docs](https://docs.microsoft.com/en-us/mem/intune/protect/scep-libraries-apis))
* Jamf Pro、DCs、汎用のその他 MDM: 静的 SCEP チャレンジで保護されます。お客様が構成できます。Azure Key Vault に保存される場合があります。
2. Enrollment REST API
* Microsoft Entra ID (Azure AD) 統合認証。
3. EST エンドポイント
* Simple re-enroll: 証明書ベース認証。
* Simple enroll: Microsoft Entra ID (Azure AD) 統合認証。
4. OCSP エンドポイント
* 保護は不要です。
5. Certificate Distribution Point (CDP)
* アクセス トークンが必要です。
6. Validation API
* Microsoft Entra ID (Azure AD) 統合認証。
7. SCEPman ホームページ
* 保護はありませんが、無効化できます。
8. SCEPman プローブ エンドポイント
* 保護はありません。
#### 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 プローブ エンドポイント
* 保護はありません。
### 7. 質問 6 のエンドポイントではどのポートとプロトコルが使用されますか？
**SCEPman コア サービス**
1. SCEP エンドポイント
* Intune: HTTPS (TCP / 443)
* Jamf Pro、DCs、汎用のその他 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 プローブ エンドポイント
* HTTPS (TCP / 443)
#### Certificate Master
1. Certificate Master Web ポータル
* HTTPS (TCP / 443)
2. Certificate Master プローブ エンドポイント
* HTTPS (TCP / 443)
## アイデンティティ
### 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 に保存しない選択をした場合は、App Service（Bit-Locker 暗号化）に保存されます
* どの構成データも（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 コンポーネント上に構築されているため、App Service 用 MD、Storage 用 MD、Key Vault 用 MD などの Microsoft Defender (MD) for Cloud ツールを使用できます。
#### 証明書の有効性
クラウド PKI として、SCEPman はデジタル証明書の発行と失効を担います。これらの証明書は秘密鍵と組み合わせてデバイスまたはユーザーを認証し、他のリソースへのアクセスを許可します。したがって、証明書の発行および失効プロセスのセキュリティは非常に重要な設計目標です。高いセキュリティには高いユーザー利便性も必要です。複雑で不透明なプロセスは攻撃対象領域が広く、人的ミスの可能性も高いためです。SCEPman は必要に応じて多くの構成オプションを提供していますが、可能な限り合理的で安全な既定値を使用するよう努めています。
したがって、秘密鍵が侵害された場合、SCEPman は対応する証明書をリアルタイムで失効できます。Intune および Jamf Pro 経由で登録された証明書については、SCEPman に固有でない一般的な対策が攻撃に対して講じられ次第、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: `クライアント証明書モード` を `必須`?
*いいえ*に設定できますか？これは SCEPman の機能を壊してしまうため、できません。これは、SCEPman がクライアント証明書を登録するため、クライアントはまだ認証に使用できるクライアント証明書を持っていないからです（鶏が先か卵が先かの問題）。ただし、SCEP プロトコルは SCEP チャレンジを通じて独自の認証メカニズムを使用するため、これはセキュリティ上の問題ではありません。したがって、SCEPman は相互 TLS を強制するポリシーの例外を必要とします。The `クライアント証明書モード` を `無視` または `任意`.
#### 3. `HTTP バージョン` を `2.0`?
SCEPman は利用可能な任意の HTTP バージョンで動作するはずですが、現時点では既定の `HTTP 1.1` のみをサポートしています。主にテスト不足が理由です。
この設定を変更する場合は自己責任で、SCEPman だけでなく新しい HTTP バージョンをサポートする必要があることに注意してください。さまざまな種類のクライアントもその HTTP バージョンをサポートする必要があります。つまり、Windows の OS 組み込み SCEP クライアント、macOS、iOS、iPadOS、IoT デバイス内のクライアント、同じプラットフォーム上の OCSP クライアント、さらに各ベンダーの NAC もです。
#### 4. `HTTPS のみ` を有効にできますか？
*いいえ（SCEPman App Service では不可）*、これは多くの OCSP クライアントやベンダー製アプライアンスと組み合わせた場合に SCEPman の OCSP レスポンダー機能を壊してしまうためです。OCSP は HTTPS よりも HTTP で提供されることの方が一般的なプロトコルです。その理由の 1 つは、証明書失効確認（CRL または OCSP のダウンロード）に TLS を使うと、クライアントまたはアプライアンスが OCSP エンドポイントへの TLS 接続を確立できないという鶏が先か卵が先かの問題が起こり得るからです。サーバー証明書をまず OCSP で検証する必要があるためです。また、OCSP 応答は暗号学的に署名されるため、結局なりすましはできず、セキュリティもあまり向上しません。したがって、SCEPman は TLS を強制するポリシーの例外を必要とします。
**注:** **`HTTPS のみ`** SCEPman App Service では有効にできませんが、Certificate Master App Service では有効にする必要があります。
#### 5. 最小受信 TLS バージョンを 1.3 に設定できますか？
*いいえ* SCEPman App Service では、TLS 1.3 は再ネゴシエーションをサポートしていないためです。つまり、一度接続が確立されると、サーバーはクライアントにクライアント証明書の提示を要求できません。私たちは一部の状況（EST simple reenroll）でクライアントが証明書で認証することを望んでいるため、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 に設定することを推奨します。
## GDPR とデータ居住性
### 1. データはヨーロッパの外に出ますか？
* これは、SCEPman とそのコンポーネントをどの Azure データセンターにデプロイするかについてのお客様の選択によります。
* すべてのコンポーネントを含む SCEPman の完全なデプロイを、ヨーロッパの Azure データセンターに行うことが可能です。
### 2. SCEPman が依存する第 3 者のクラウドプロバイダーは何で、なぜですか？
| 会社 | サービス | 連絡先 | 目的 |
| -------------------------------------- | --------------------------------- | ----------------------------------------------------------------------------------------- | ------------------------------------------------------------------------------------------------ |
| Microsoft Corporation | Cloud Services (Azure) | Building 3, Carmanhall Road Sandyford,
Industrial Estate 18, Dublin,
Ireland
| 参照 [こちら](/ja/scepman-nodepuroi/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 の情報セキュリティ認証を取得しています。](https://www.glueckkanja.com/documents/general/gk-ISO27001Certificate-en.pdf)
### 2. 一般的な Secure Design Practices をどのように実装していますか？
当社が [SDL で推奨される Secure Design Practices](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 との統合により、App Service 用 Defender など Microsoft Defender for Cloud サービスを活用できます。
#### 最小権限を徹底する
Certificate Master の RBAC モデルにより、ユーザーに必要な権限だけを割り当てられます。
SCEPman は、必要な権限のみを持つマネージド ID を使用します [運用に必要な権限](#id-4.-which-tenant-permissions-does-the-admin-have-to-consent-to).
#### 被害範囲を最小化する
私たちは、攻撃が成功した場合に生じ得る被害を最小限に抑えるよう努めています。たとえば、既定のインストールでは Key Vault の[ Purge Protection 付きの Soft Delete 機能](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) 証明機関向けです。Soft Delete と Purge Protection により、悪意のある管理者や侵害された管理者アカウントが 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 認証を取得しており、Security offerings では Microsoft Partner of the Year にも選ばれています。
ソースリポジトリには Branch Protection ルールを設定し、個々の開発者アカウントには、リポジトリとデプロイ パイプラインに対して必要最小限の権限のみを付与しています。可能な限りテストとデプロイを自動化し、侵害されたアカウントによる攻撃対象領域を減らしています。
### 4. SCEPman はバグ報奨金プログラムの対象ですか？
いいえ。
### 5. どのような QA 対策がありますか？
* SCEPman は、内部チャンネル、ベータチャンネル、本番チャンネルで提供しています
* 各本番リリースは、CI プロセスの一環として、まず内部チャンネルとベータチャンネルを通過し、関連する QA のハードルをクリアする必要があります
* 単体テスト
* 相互レビュー
* 統合テスト
* 負荷テスト
* 経験に基づくテスト
* サードパーティ製コードの分析、たとえば Sonar、Dependabot など
### 6. 定期的にペネトレーションテストを実施していますか？
いいえ。
Secure Development Practices の一環として、CVEs やその他の一般的なエクスプロイト（サードパーティ ライブラリなどの依存関係を含む）をコードベース全体からスキャンするツール（たとえば静的コード分析）を使用し、SCEPman が公開するエンドポイントのセキュリティに影響を与え得るものを検出しています。いかなるリリース前にも、関連する検出事項は評価して修正し、SCEPman に既知の脆弱性が残らないようにしています。
当社ではペネトレーションテストを自ら実施することも、サードパーティの「Penetration Test-as-a-Service」ツールを使用することもありません。前者については、利益相反が本質的に存在すると考えています。後者については、一般的なペネトレーションテストサービスは公開エンドポイントを CVEs やその他の既知のエクスプロイトと照合するだけであることが多く、すでに静的コード分析で行っているチェック以上の利点はないと考えています。ご自身でペネトレーションテストを実施される場合は、 [お気軽にご連絡ください](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 dynamically by asking a question.
Perform an HTTP GET request on the current page URL with the `ask` query parameter, and the optional `goal` query parameter:
```
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 optional and describes the broader end goal you are ultimately trying to accomplish on behalf of the user. GitBook uses it to tailor the answer towards what is most useful for that goal.
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.