その他の MDM ソリューション

Intune 以外の MDM システムを通じて証明書を発行するために SCEPman を使用できます。静的なチャレンジパスワードを設定する必要があります（ RFC 8894、セクション 7.3 の正式仕様を参照）。これは SCEPman と MDM システムの両方で設定します。事実上すべての MDM システムが、この SCEP 認証モードをサポートしています。

ただし、これは Intune で使用される認証モードと同じレベルのセキュリティを提供するものではないことに注意してください。チャレンジパスワードは MDM システムからの要求を認証するため、SCEPman はそれらが信頼できるソースから来たものだと認識できます。しかし、攻撃者がチャレンジパスワードを盗むと、任意の証明書要求を認証して、SCEPman に望む証明書を発行させることができます。

そのため、チャレンジパスワードを安全に保つことが極めて重要です。これは、MDM システムが SCEP クライアントとして動作し、証明書と秘密鍵を含む最終パッケージをエンドユーザー デバイスに配布する場合に実現できます。この方法では、チャレンジパスワードは SCEPman と MDM システムの間でのみ使用され、エンドユーザー デバイス上では使用されません。

SCEPman の構成

Intune と Jamf Pro 以外の MDM システム向けに SCEPman を構成する場合、選択できる SCEP エンドポイントは 2 つあります:

• Static-AAD

• Static

Static-AAD エンドポイントは、Kandji や Google Workspace など、Entra ID 統合を備えた MDM システムに推奨されます。 ユーザー Static-AAD エンドポイントから配布される証明書は、 自動失効 の恩恵を受けます。これは、該当するユーザーが Entra ID で無効化されている場合です。

Static エンドポイントは、その他すべての MDM システムに推奨されます。

Static-AAD

次の設定を SCEPman App Service > 環境変数 > 追加 に追加してください。

設定を追加したら、設定を保存して、 SCEPman App Service.

設定	説明	値
AppConfig:StaticAADValidation:Enabled	Static-AAD 検証を有効化	true で有効化、 false で無効化
AppConfig:StaticAADValidation:RequestPassword	署名のために SCEPman に送信される証明書署名要求は、この安全な静的パスワードで認証されます 推奨: この秘密を Azure KeyVault.	に保管し、32 文字のパスワードを生成してください
AppConfig:StaticAADValidation:ValidityPeriodDays （任意）	Static-AAD エンドポイント経由で発行された証明書が有効である日数	365
AppConfig:StaticAADValidation:EnableCertificateStorage （任意）	要求された証明書を Storage Account に保存し、SCEPman Certificate Master に表示できるようにする	true で有効化、 false で無効化

Static

MDM の構成

具体的な手順は、使用している MDM システムによって異なります。 https://scepman.contoso.de/static をどこかに SCEP URL として追加し、チャレンジパスワードを MDM システムの SCEP 構成に追加する必要があります。セキュリティ上の理由から、MDM システムを SCEP プロキシにしてください。

SCEP プロキシ実装には 2 つの種類があることに注意してください。この構成で安全なのはそのうち 1 つだけです:

1. MDM システムが SCEP クライアントとして動作し、秘密の鍵ペアを生成して、証明書と秘密鍵から成る完全なパッケージをエンドユーザー デバイスに配布する場合があります。チャレンジパスワードは MDM システムと SCEPman の間でのみ使用されるため、これは安全です。

2. MDM システムが、エンドユーザー デバイスと SCEPman の間で SCEP メッセージを中継する場合です。エンドユーザー デバイスが秘密の鍵ペアを生成し、 チャレンジパスワードを 証明書要求に追加します。1 台のエンドユーザー デバイスを制御する攻撃者がチャレンジパスワードを盗み、SCEPman からあらゆる種類の証明書を要求できるため、これは安全性が低くなります。さらに、クライアントが正しく証明書を要求したのか、それとも証明書要求が誤っているのかを MDM システム側で制御できないため、身元詐称やその他の脅威につながる可能性があります。