セキュリティとプライバシー

この章では、情報セキュリティ、プライバシー、および品質保証に関するよくある質問の概要を提供します。

データ処理と権限

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. 構成

   • 構成データには常に SCEPman CA の公開/秘密鍵ペアと証明書が含まれ、これらは Azure Key Vault に安全に保管されます。

   • さらに、構成データには静的な SCEP チャレンジやパスワードなどのシークレットが含まれる場合があります。これらのパラメーターの目的は SCEPman のドキュメントで説明されています。

   • すべての構成パラメーターは、セキュリティを強化するために Azure Key Vault に保存できます。

2. 発行された証明書

   • 発行されたすべての証明書は Azure Storage アカウントに保存されます - 秘密鍵を除く.

   • 証明書の一部となる可能性のあるデータについては、 質問 1.

   • この動作は 無効化.

   • Certificate Master を介して証明書を発行する際、要求者（Microsoft Entra ID (Azure AD) UPN）が保存されます。

   • Certificate Master を介して証明書を失効させる際、証明書の失効状況とそれを失効させたユーザーの識別（Microsoft Entra ID (Azure AD) UPN）が保存されます。

3. ログ記録

   SCEPman のログ記録は顧客の設定に基づいて有効化される場合があります。顧客のログ詳細度設定に依存して、ログには SCEPman が処理する任意のデータが含まれる可能性があります。ログの保存場所は顧客が設定します。

4. 外部 Log Analytics ワークスペース

   SCEPman は常に限定された量の 非機密 および 非個人情報 データを当社の Log Analytics ワークスペース（LAW）に送信します。このデータは

   • ライセンスの目的

   • 品質保証（例：例外をグローバルに監視することで一般的かつ広範な問題を迅速に認識でき、クライアントに迅速な対応を提供して高額なサービス停止を防ぐことができます）に使用されます。

   デフォルトでは、SCEPman は 当社の LAW に個人データを送信しません 。

   ログ設定によっては、デバッグやその他の情報が glueckkanja-gab AG の LAW に転送されます。サポート担当のエンジニアはトラブルシューティングのために顧客管理者に 有効化 を依頼する場合があります。そのような場合、証明書要求に関する情報が当社の LAW アカウントに送信されることがあり得ます（証明書に含める情報は顧客が決定します）。個人データを含む可能性がある情報の例：

   • ユーザー名

   • メール

   • Microsoft Entra ID (Azure AD) UPN

   • デバイス識別子

   当社は定期的に すべての ログデータを次の間隔で削除します：

   • 30 日

3. SCEPman はどの地域（地理的に）でデータを処理および保存しますか？

設計上、SCEPman は Azure アプリ（ソリューションテンプレートベース）として実現されており、つまり顧客の Azure テナントにデプロイされます。そのため、ホスティングデータセンターの地理的な場所の選択を含むデータ主権は顧客の管理下にあり、顧客の選好に従います。

外部 Log Analytics ワークスペース

ライセンス強制の目的で（デフォルトで）テレメトリ情報を収集するために利用する外部の 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 は、使用時に Intune 経由で発行済み証明書の一覧を要求します EndpointList 廃止機能.

4. Microsoft Graph IdentityRiskyUser.Read.All： この権限により、SCEPman は自動的に AAD ユーザリスクが構成されたしきい値を超えた場合にユーザー証明書を取り消すことができます.

Jamf Pro

1. ユーザー、コンピュータ、デバイスに対する読み取り権限 これらの権限により、SCEPman は Jamf Pro に照会して、ユーザーまたはデバイスの証明書が認可されたユーザーやデバイスから発行されたものであるかを確認できます。

Certificate Master

1. Microsoft Graph User.Read （アプリ登録経由）： この権限により、Certificate Master は誰が手動で証明書を要求または取り消したかを判断します。

2. Micrsoft Graph DeviceManagementManagedDevices.Read.All および DeviceManagementConfiguration.Read.All （Managed Identity として）： これらの権限により、Certificate Master は Intune 経由で発行済み証明書の一覧を要求します。管理者はこれらの証明書を確認し、手動で取り消すことができます。

5. SCEPman は外部からアクセス可能などのエンドポイントを公開しますか？

SCEPman コアサービス

1. SCEP エンドポイント

   • SCEP リクエストに対して呼び出されます。

   • 設定に基づき、SCEPman は Intune、Jamf Pro、DC、汎用の他の MDM 向けに複数の SCEP エンドポイントを公開する場合があります。

2. Enrollment REST API

   • Certificate Master が SCEPman のコアサービスから証明書を要求できるようにします。

   • カスタムアプリケーションが SCEPman のコアサービスから証明書を要求できるようにします。

3. EST エンドポイント

   • EST の単純な再登録（re-enroll）要求のために呼び出されます。設定により有効化できます。

   • EST の単純な登録（enroll）要求のために呼び出されます。

4. OCSP エンドポイント

   • OCSP リクエストに対して呼び出されます。

5. 証明書配布ポイント（CDP）

   • 証明書失効リスト（CRL）はこのエンドポイントを通じて提供されます。

   • で有効化できます 設定.

6. 検証 API

   • Certificate Master が証明書の自動取り消し状態を評価できるようにします。

7. SCEPman ホームページ

   • SCEPman の基本的なステータス情報を公開（機密情報は含まれません）して表示します。

   • 読み取り専用です。

   • で無効化できます 設定.

8. SCEPman プローブエンドポイント

   • ヘルス チェック: 統合された App Service ヘルス チェック、Traffic Manager のプローブ、Application Gateway のプローブ。

Certificate Master

1. Certificate Master ウェブポータル

   • サーバー証明書を手動で発行し、CSR に署名します。

   • Certificate Master 経由で発行された証明書を手動で失効させます。

   • 手動で発行された証明書の一覧を表示します。

2. Certificate Master プローブエンドポイント

   • ヘルス チェック: 統合された App Service ヘルス チェック

6. 質問 5 のエンドポイントはどのように保護されていますか？

SCEPman コアサービス

1. SCEP エンドポイント

   • Intune: Intune Challenge API によって保護されています (Microsoft Docs)

   • Jamf Pro、ドメインコントローラー、その他の一般的な 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 プローブエンドポイント

   • 保護なし。

Certificate Master

1. Certificate Master ウェブポータル

   • Microsoft Entra ID (Azure AD) 統合認証。

   • Microsoft Entra ID (Azure AD) ロール割り当て.

2. Certificate Master プローブエンドポイント

   • 保護なし。

7. 質問 6 のエンドポイントではどのポートとプロトコルが使用されていますか？

SCEPman コアサービス

1. SCEP エンドポイント

   • Intune: HTTPS (TCP / 443)

   • Jamf Pro、ドメインコントローラー、その他の一般的な 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 プローブエンドポイント

   • HTTPS (TCP / 443)

Certificate Master

1. Certificate Master ウェブポータル

   • HTTPS (TCP / 443)

2. Certificate Master プローブエンドポイント

   • 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 Service）は、関連する Azure 権限を持つ承認済みユーザーのみがアクセスできます。

暗号鍵

• CA の秘密鍵は Azure Key Vault に安全に保存されています (FIPS 140 検証済み HSM がデフォルトで使用されています)。

• 秘密鍵は読み取りやエクスポートができません。

• 秘密鍵は不正な管理者による削除から保護されています (パージ保護とソフト削除 がデフォルトで有効になっています)。

• Azure Key Vault はプライベートエンドポイントを使用しており、SCEPman からのみアクセスできます（バージョン 2.8 以上の SCEPman インストールのデフォルト）。

証明書データベース

• このデータベースは Azure ストレージ アカウントの Table サービスを使用します。したがって、保護は Azure に組み込まれた仕組みに依存します。

• 特に、Azure はデータへのアクセス権を管理するためにロールベースのアクセス制御を採用しています。

• Azure Storage はデータベース暗号化を使用し、カスタマー管理キーをサポートします。

• Azure ストレージ アカウントはプライベート エンドポイントを使用しており、SCEPman からのみアクセス可能です（SCEPman バージョン 2.8 以降の標準設定）。

ログ

• ログは 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 ウェブポータル:

  • 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 用の Microsoft Defender、Storage 用の Microsoft Defender、Key Vault 用の Microsoft Defender などの Microsoft Defender for Cloud ツールを利用できます。

証明書の有効性

クラウド PKI として、SCEPman はデジタル証明書の発行と失効に責任を負います。これらの証明書は対応する秘密鍵とともにデバイスやユーザーを認証し、他のリソースへのアクセスを許可します。したがって、証明書発行および失効プロセスのセキュリティは非常に重要な設計目標です。高いセキュリティを実現するには高いユーザー利便性も必要です。なぜなら、複雑で不透明なプロセスは攻撃対象領域が広くなり、人為的ミスの可能性が高くなるためです。必要に応じて SCEPman は多くの構成オプションを提供しますが、可能な限り合理的で安全なデフォルトを使用するよう努めています。

したがって、秘密鍵が漏洩した場合、SCEPman は対応する証明書をリアルタイムで失効させることができます。Intune および Jamf Pro を介して登録された証明書については、SCEPman は SCEPman 固有でない一般的な対策が攻撃に対して講じられ次第、自動的にこれを行います。あなたが行うべきことは 対応する Intune を削除すること または Jamf Pro のオブジェクトです。

デバイスの廃棄プロセスに応じて、さらに次のように構成することもできます： ワイプが実行されたときに証明書を失効させる、 Intune が失効を要求したとき、次の条件に応じて デバイスのコンプライアンス または ユーザーのリスク レベル、あるいは Certificate Master コンポーネントを通じて単一の証明書を手動で失効させることができます。

手動で作成された証明書は 常に手動での失効が必要です。

2. SCEPman の設計に使用された技術、スタック、プラットフォームは何ですか？

• C#

• ASP.NET Core MVC

• Bouncy Castle 暗号 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 暗号ライブラリがサポートするもの）).

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 はルート CA の公開鍵・秘密鍵ペアをお客様のテナント内の Azure Key Vault に生成します。したがって、ルート CA はお客様固有の SCEPman インスタンスに対してユニークであり、CA、CA 証明書および対応する秘密鍵を完全に管理できます。

• この CA へのアクセスは、必要に応じて変更可能な Key Vault のアクセスポリシーによって制御されます。デフォルトでは、あなた自身の SCEPman インスタンスだけが証明書を使用でき、他の誰も（管理者も含めて）使用できませんが、サブスクリプション管理者は追加の権限を付与できます。

• したがって、他の SCEPman 顧客はどのように SCEPman を構成してもあなたの VPN に接続することはできません。たとえ同じ組織名を選択しても、彼らは独自の鍵ペアと別の CA 証明書を持つため、あなたの VPN ゲートウェイはそれを信頼しません。

Azure CIS

このセクションは、Azure 環境のサイバーディフェンスポリシーを定義する際や、以下のようなベストプラクティスフレームワークに取り組む際に生じる疑問を扱います： CIS Microsoft Azure Foundations ベンチマーク.

Storage アカウント

1. 次の設定は Blob のパブリックアクセスを許可する 無効にできますか？

はい、これは実際に新しい SCEPman インストールのデフォルトです。

App Services

2. TLS：次の設定は可能ですか クライアント証明書モード を次に設定することはできますか 必須?

いいえ、これは SCEPman の機能を破壊するため設定できません。これは SCEPman がクライアント証明書を登録するため、クライアントはまだ認証に使用するクライアント証明書を持っていない（鶏と卵の問題）からです。ただしこれはセキュリティ上の問題ではありません。SCEP プロトコルは SCEP チャレンジを通じた独自の認証機構を使用するためです。したがって、SCEPman は相互 TLS を強制するポリシーからの例外が必要です。 クライアント証明書モード 次の項目は 無視 または 任意.

3. 次の設定は可能ですか HTTP バージョン を次に設定することはできますか 2.0?

SCEPman は利用可能などの HTTP バージョンでも動作するはずですが、現時点では主にテスト不足のためデフォルトの HTTP 1.1 をサポートしています。

この設定を変更する場合（自己責任で）、SCEPman だけでなくクライアント側もその新しい HTTP バージョンをサポートする必要があることに注意してください。つまり、Windows、macOS、iOS、iPadOS の OS 組み込みの SCEP クライアント、IoT デバイス内のクライアント、同プラットフォーム上の OCSP クライアント、さらにベンダーの NAC など、多様なクライアントがその HTTP バージョンをサポートする必要があります。

4. 次の設定は可能ですか HTTPS のみ を有効にできますか？

いいえ（SCEPman App Service には該当しません）、これは多くの OCSP クライアントやベンダー製アプライアンスと組み合わせた場合に SCEPman の OCSP レスポンダ機能を破壊するため有効にできません。OCSP は HTTPS よりも HTTP 経由で提供されることが一般的です。その理由の一つは、証明書失効確認（CRL や OCSP のダウンロード）に TLS を使うと、クライアントやアプライアンスが OCSP エンドポイントへの TLS 接続を確立できないという鶏と卵の問題が発生し得るためです。また、OCSP 応答は暗号的に署名されているため改ざんができず、TLS を使っても大きな追加的な安全性が得られるわけではありません。したがって、SCEPman は TLS を強制するポリシーからの例外が必要です。

注： HTTPS のみ は SCEPman App Service では有効にできませんが、Certificate Master App Service では有効にするべきです。

5. Minimum Inbound TLS Version を 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 登録中のエラー).

注： Certificate Master App Service にはブラウザのみがアクセスするため、Certificate Master については Minimum Inbound TLS Version を 1.3 に設定することが推奨されます。

GDPR とデータ居住性

1. データはヨーロッパを出ますか？

• これは SCEPman とそのコンポーネントをどの Azure データセンターにデプロイするかという顧客の選択によります。

• SCEPman のすべてのコンポーネントを含む完全なデプロイをヨーロッパの Azure データセンターに行うことは可能です。

2. SCEPman が依存するサードパーティのクラウドプロバイダーは何で、なぜですか？

会社	サービス	連絡先	目的
Microsoft Corporation	クラウドサービス（Azure）	Building 3, Carmanhall Road Sandyford, Industrial Estate 18, Dublin, Ireland	参照 ここ.
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。SDL の実践を採用することで、安全なコードとデプロイを作成するのに役立ちます。 当社の製品開発は ISO 27001 情報セキュリティ認証を取得しています。

2. 一般的なセキュア設計の実践はどのように実装していますか？

これが私たちが実装している方法です： SDL が推奨するセキュア設計の実践:

チームとしての設計と脅威モデル

私たちの脅威モデリングの実践は次の推奨に基づいています： Tufts Security and Privacy Lab の推奨。私たちは多様な開発者チーム、当社の CSOC および PKI コンサルタント、サポートチームとともに設計上の決定と潜在的な STRIDE 脅威を議論します。

プラットフォームのセキュリティをカスタムコードより優先

可能な場合は、再発明するのではなく .NET や確立されたライブラリ（できればオープンソース）から機能を利用します。たとえば、暗号データ標準を扱うために Legion of the Bouncy Castle C# を使用しています。また、暗号鍵の生成に Azure Key Vault、ウェブサーバーホスティングに App Services、ログに Azure Monitor、データベースエンジンとして Azure Storage など、Azure のサービスに依存しています。

安全な構成がデフォルト

人的ミスの可能性を最小化するため、デフォルトを使用した場合に安全な構成になるよう製品を設計します。たとえば、私たちの ARM テンプレート および私たちの Terraform プロバイダー は設定を 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 は運用に必要な 権限のみを持つマネージド ID を使用します。.

被害範囲の最小化

攻撃が成功した場合の被害を最小化するよう努めています。たとえば、デフォルトのインストールでは Key Vault の ソフトデリート機能とパージ保護を有効にします。 とともに エクスポート不可の HSM バックの秘密鍵 を認証局用に使用します。ソフトデリートとパージ保護により、悪意ある管理者や乗っ取られた管理者アカウントが CA の秘密鍵を削除できないことが保証されます — 通常の運用を継続するために数分で復元でき、グローバル管理者であっても 90 日の期間が経過するまではパージできません。エクスポート不可の HSM バックの CA 鍵により、最高権限を持つ攻撃者であっても CA 鍵を盗むことができないようにします。

攻撃対象面の最小化

顧客の運用に必要なインターフェースのみを公開するようにしています。SCEP エンドポイントが未設定であれば、SCEP リクエストは処理されません。

を使用して、 プライベート エンドポイントSCEPman が依存する 2 つのサービス、Azure Key Vault と Azure Storage がインターネット経由で到達できないようにしています。

悪用ケースを考慮する

SCEPman が認可された証明書署名要求（CSR）を受け取った場合でも、いくつかの設定可能な制限の対象となります。たとえば、有効期間は要求されていても決して 設定された最大有効期間を超えることはできません。

セキュリティイベントの監視とアラート

SCEPman がセキュリティイベントを検出した場合、それらはログに Warning または Error として記録されます。Azure Monitor および Azure Event Hub との統合により、 アラートの設定 やこれらのセキュリティイベントを SIEM で分析することが容易になります。

3. 自社の開発環境はどのように保護していますか？

CSOC サービスとセキュリティコンサルティングも提供する企業の一部として、私たちはデバイス、プロセス、ユーザーの意識向上に関して高いセキュリティ基準を持っています。私たちは Microsoft MISA に参加しており、ISO 27001 認証を取得し、セキュリティ分野での Microsoft Partner of the Year を受賞しています。

ソースリポジトリにはブランチ保護ルールがあり、リポジトリやデプロイパイプラインに対して個々の開発者アカウントへは必要最小限の権限のみを割り当てています。可能な限りテストとデプロイを自動化して、乗っ取られたアカウントによる攻撃対象面を減らしています。

4. SCEPman はバグバウンティプログラムに参加していますか？

いいえ。

5. どのような QA 対策がありますか？

• SCEPman は内部チャネル、ベータチャネル、プロダクションチャネルで提供しています。

• 各プロダクションリリースはまず内部およびベータチャネルを通過し、CI プロセスの一環として関連する QA のハードルをクリアする必要があります。

  • 単体テスト（Unit tests）

  • ピアレビュー

  • 統合テスト

  • 負荷テスト

  • 経験に基づくテスト

  • サードパーティのコード解析、例：Sonar、Dependabot、その他

6. 定期的にペネトレーションテストを実施していますか？

いいえ。

セキュア開発の実践の一環として、静的コード解析などのツールを用いてコードベースをスキャンし、CVE やその他の一般的なエクスプロイト（サードパーティライブラリなどの依存関係を含む）を検出しています。リリース前に関連する発見事項は評価され是正され、SCEPman が既知の脆弱性から解放されるようにしています。我々は自社でのペネトレーションテストを実施しておらず、またサードパーティの「Penetration Test-as-a-Service」ツールも使用していません。前者については利益相反の懸念があります。後者については、一般的なペネトレーションテストサービスが公開エンドポイントを CVE や既知のエクスプロイトに対してチェックするにとどまることが多いため、静的コード解析で既に行っているチェックに追加価値があるとは考えていないためです。独自にペネトレーションテストを実施したい場合は、 お問い合わせください そして要件をお知らせください。