拡張ガイド

SCEPman エンタープライズ版のみ

これは、命名規則、冗長性、自動スケーリングなどの高度な要件を伴うエンタープライズグレードの環境向けに SCEPman を展開するためのすべての手順を案内します。

Azure デプロイメント

まずは前提条件とリソースの概要から始めます。 有用な Azure リソース設計を計画する必要があることを忘れないでください。

前提条件

必須

• Azure リソースの命名規則。

• Azure サブスクリプション（該当サブスクリプションに対する少なくとも Contributor 権限）。

• Azure オーナー権限（少なくともリソース グループレベルで）。

• Microsoft Entra ID (Azure AD) の「グローバル管理者」（Graph API へのアクセスに対する同意）。

• SCEPman の要件に従って Azure ポリシーを定義してください SCEPman の要件に従って （例: TLS を強制しない）。

• パブリックドメインの CNAME（scepman.yourdomain.com）、ジオ冗長性を使用する場合のみ。

• SSL（ワイルドカード）証明書（または App Service 管理証明書）、ジオ冗長性を使用する場合のみ。

• SCEPman エンタープライズ版ライセンスキー。

オプション

• パブリックドメインの CNAME（scepman.yourdomain.com）、カスタムドメインを使用する場合のみ。

• SSL（ワイルドカード）証明書（または App Service 管理証明書）、カスタムドメインを使用する場合のみ。

Azure リソースの概要

これらのリソースはすべて本番環境向けに推奨されます。

さらに、Private Endpoint を使用している場合は、 さらに7つの Azure リソースがあります。

構成手順

1

SCEPman 基本サービスのデプロイ

これは 必須の ステップです。

Windows または Linux のどちらの Windows または Linux App Service プランでデプロイするか選択してください。両方のデプロイ方法でオペレーティングシステムを選択できます。

デプロイを開始するには、次のいずれかを利用したセットアップ手順に従う必要があります。 ARM テンプレート

エンタープライズデプロイ

または代わりに当社の Terraform スクリプト:

Terraform デプロイ

2

デプロイ後の手順を実行する（権限割り当て）

これは 必須の ステップです。

SCEPman のすべてのコンポーネントを適切に接続するために、いくつかの権限を割り当てる必要があります。関連する接続を確立するために、次の手順に従ってください:

マネージドID

3

Certificate Master の権限を追加する

これは 必須の ステップ（ エンタープライズ エディション ）の手順。 コミュニティエディション のユーザーはこの手順をスキップできます。

Certificate Master は エンタープライズエディションの 機能で、管理者が手動で証明書を発行および取り消しできるようにします。Certificate Master へのアクセスを提供するために、次の手順に従ってください。

Certificate Master RBAC

4

ルート証明書を作成する

これは 必須の ステップです。

デプロイおよび権限割り当てが完了したら、SCEPman のルート証明書を作成する必要があります:

ルート CA

5

カスタムドメインと SSL 証明書を構成する

これは 推奨される 手順です。ただし、 スキップ ジオ冗長性/高可用性を実装する場合はこの手順を省略してください。

SCEPman を特定のドメインで利用可能にするには、 カスタムドメイン を App Service に作成する必要があります。

カスタムドメイン

6

手動更新

これは オプションの ステップです。

既定では、SCEPman は更新に対して エバーグリーン方式 を採用します。SCEPman の更新を完全に制御する必要がある場合は、次のガイドの「 デプロイメントスロットの構成.

更新戦略

7

」のセクションで説明されているようにデプロイメントスロットを構成してください。

Application Insights をデプロイする 推奨される ステップです。

これは

Application Insights

8

Application Insights は App Service のパフォーマンス概要を取得し、SCEPman のリクエスト処理の詳細な洞察を得るために使用できます。App Service を監視、保守、最適化するために、常に Application Insights を構成することを推奨します。

Application Insights をデプロイする 推奨される ステップです。

ヘルスチェックを構成する

ヘルスチェック

9

ヘルスチェックは、SCEPman App Service が応答しない場合に管理者に通知するよう構成できます。

これは 必須の ステップです。

SCEPman に十分なリソースがあることを確認する

App Service のサイズ設定

10

SCEPman を本番環境に移行する際は、SCEPman に十分な計算リソースが備わっていることを確認してください。そのため、当社の Azure サイズガイドを確認し、必要に応じて App Service プランの階層をアップグレードしてください。これは PoC またはトライアル段階の後に延期することもできます。

これは オプションの ステップです。

オートスケーリングを構成する

SCEPman ソリューションには2つの異なるタスクとパフォーマンス要件があります。 1つ目のタスクは証明書発行プロセスです: SCEPman ソリューションの構成後、全てのデバイスに証明書を展開する必要があります（ユーザーおよび/またはデバイス証明書）が、これは一度限りのタスクであり、初期デプロイ後は新しいデバイスが登録された場合や証明書を更新する必要がある場合にのみ発生します。そのような状況では、SCEPman は SCEP リクエストのピークに直面します。

2つ目のタスクは証明書検証です: デバイスに証明書を展開した後、それらの証明書は使用されるたびに検証される必要があります。証明書ベースの認証ごとに、クライアント、ゲートウェイ、または RADIUS システム（使用する構成による）は SCEPman App Service に OCSP リクエストを送信します。これにより App Service に対する恒常的なリクエスト負荷が発生します。

オートスケーリング

11

最適なパフォーマンスを確保しコストを管理するために、App Service のオートスケーリング機能の設定を推奨します。この機能により、アプリケーションはメトリクスに基づいてスケールアウトおよびスケールインできます。

これは オプションの ステップです。

ジオ冗長性を構成する

SCEPman のジオ冗長インスタンスを構成すると、複数の Azure リージョンにワークロードを分散することでサービスの可用性と回復力を向上させることができます。

地理的冗長化

12

ただし、この構成は追加のリソースやデータ複製を伴うため、Azure コストの増加につながる可能性があることに注意してください。Microsoft は Azure App Services に対して 99.95% の SLA を提供しており、ほとんどのシナリオで十分です。

これは 推奨される ステップです。

MDM 展開プロファイルを構成する

上記の手順が完了したら、稼働中の SCEPman 実装ができあがり、デバイスに証明書を展開できるようになります。

Microsoft IntuneJamf Proその他の MDM ソリューション

13

好みの MDM ソリューションで証明書を展開するには、次のいずれかのドキュメントを使用してください:

これは オプションの ステップです。

Certificate Master を使用して証明書を手動で発行するか CSR に署名する

Certificate Master

14

以下のリンクに従って、FQDN のリストに基づく TLS サーバー証明書の発行方法や、Certificate Master コンポーネントを使用して任意の CSR に署名する方法を確認してください。

これは オプションの ステップです。

Enrollment REST API を使用して証明書を発行する

登録 REST API

15

SCEPman には証明書を登録するための REST API が用意されています。これは SCEP 方式の認証を必要とする SCEP エンドポイントの代替手段であり、REST API は認証に Microsoft Identities を使用します。プロトコルも SCEP よりはるかにシンプルです。

これは オプションの ステップです。

SCEPman Azure リソースにロックを作成する

• デフォルトでは、SCEPman は Azure リソースに対してロックを適用しません。リソースロックを使用しており、それらを構成したい場合は、次の一覧が各 SCEPman リソースに適用できるロックの種類を示しています。 Key Vault: ソフトデリートとパージ保護によって偶発的な削除からの保護は既に提供されています。SCEPman は CA キー作成後にリソースを変更しないため、 ReadOnlyLock

• は技術的には可能です。 Storage Account: SCEPman がテーブルに証明書情報を書き込む必要があるため、可能なのは DeleteLock

• のみです。Storage Account が誤って削除されると、すでに発行された証明書に関する情報を失います。 App Services: ソフトデリートとパージ保護によって偶発的な削除からの保護は既に提供されています。SCEPman は CA キー作成後にリソースを変更しないため、 は理論的には可能ですが、SCEPman の構成を変更するたびに削除する必要があります。削除された App Service は簡単に再インストールできますが、デフォルト構成しか持たないため、すべての手動変更を再設定する必要があります。 SCEPman がテーブルに証明書情報を書き込む必要があるため、可能なのは そして ソフトデリートとパージ保護によって偶発的な削除からの保護は既に提供されています。SCEPman は CA キー作成後にリソースを変更しないため、 の組み合わせがこのリスクを軽減するのに役立ちます。

• Log Analytics Workspace: App Services: SCEPman がテーブルに証明書情報を書き込む必要があるため、可能なのは は技術的には可能ですが、保持期間中に収集されたログしか失われないため、SCEPman サービスの可用性には影響しません。

• その他の Azure リソース: これらはデータを保存しないため、情報を失うことなく再作成できます。いくつかのリソースには SCEPman がテーブルに証明書情報を書き込む必要があるため、可能なのは そして ソフトデリートとパージ保護によって偶発的な削除からの保護は既に提供されています。SCEPman は CA キー作成後にリソースを変更しないため、 が有用な場合があります。上記のいずれかのコアサービスに依存関係があるため、削除できないものもあります。