拡張ガイド

SCEPman Enterprise Edition のみ

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

Azure デプロイ

まずは要件とリソースの概要から始めましょう。 有用な Azure リソース設計を計画する必要があることを念頭に置いてください。

前提条件

必須

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

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

• Azure の所有者権限（少なくとも Resource Group レベル）。

• Microsoft Entra ID（Azure AD）の「グローバル管理者」（Graph API へのアクセス許可の付与）。

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

• 公開ドメインの CNAME（scepman.yourdomain.com）、地理冗長性を使用する場合のみ。

• SSL 証明書（または App Service Managed Certificate）、地理冗長性を使用する場合のみ。

• SCEPman Enterprise Edition License Key。

任意

• 公開ドメインの CNAME（scepman.yourdomain.comを使用）、カスタム ドメインを使用する場合のみ。

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

Azure リソース概要

本番環境には以下のリソースを推奨します。

さらに、Private Endpoint を使用している場合は、 7 つの追加 Azure リソース。

構成手順

1

SCEPman ベース サービスをデプロイする

これは 必須の 手順です。

次のどちらでデプロイするかを選択してください。 Windows または Linux App Service Plan。どちらのデプロイ方法でも、OS を選択できます。

デプロイを開始するには、次の手順に従って、 ARM Template

Enterprise デプロイ

を利用するか、または代わりに Terraform スクリプトを使用してください:

Terraform デプロイ

2

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

これは 必須の 手順です。

SCEPman のすべてのコンポーネントを正しく関連付けるには、いくつかのアクセス許可を割り当てる必要があります。関連する接続を確立するには、次の手順に従ってください:

Managed Identities

3

Certificate Master の権限を追加する

これは 必須の の手順は Enterprise Edition のお客様向けです。 Community Edition のユーザーはこの手順を省略できます。

Certificate Master は Enterprise Edition の機能で、管理者が証明書を手動で生成および失効できるようにします。Certificate Master へのアクセスを提供するには、次の手順に従ってください。

Certificate Master RBAC

4

ルート証明書の作成

これは 必須の 手順です。

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

ルート CA

5

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

これは 推奨されます の手順。ただし、 スキップ してください。地理冗長性を実装する場合はこの手順をスキップします。

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

カスタム ドメイン

6

手動更新

これは 任意の 手順です。

既定では、SCEPman は更新に対して エバーグリーン アプローチ を採用しています。SCEPman の更新を完全に制御する必要がある場合は、次のガイドのセクションに記載されているとおり、デプロイ スロットを構成してください デプロイ スロットの構成.

更新戦略

7

Application Insights をデプロイする

これは 推奨されます 手順です。

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

Application Insights

8

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

これは 推奨されます 手順です。

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

ヘルス チェック

9

SCEPman に十分なリソースがあることを確認してください

これは 必須の 手順です。

SCEPman を本番環境に移行したら、十分なコンピューティング ক্ষম力が備わっていることを確認する必要があります。そのため、Azure サイジング ガイドを確認し、必要に応じて App Service Plan の階層をアップグレードしてください。これは PoC または試用期間の後まで延期してもかまいません。

App Service のサイズ設定

10

自動スケーリングを構成する

これは 任意の 手順です。

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

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

最適なパフォーマンスを確保し、コストに配慮するために、App Service の自動スケーリング機能を構成することを推奨します。この機能により、メトリックに基づいてアプリケーションをスケールアウトおよびスケールインできます。

自動スケーリング

11

地理冗長性を構成する

これは 任意の 手順です。

SCEPman に地理冗長インスタンスを構成すると、複数の Azure リージョンにワークロードを分散することで、サービスの可用性と耐障害性を向上できます。

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

ジオ冗長

12

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

これは 推奨されます 手順です。

上記の手順が完了すると、SCEPman の動作する実装が用意でき、デバイスへの証明書のデプロイが可能になります。

ご希望の MDM ソリューションで証明書をデプロイするには、次のいずれか（または複数）の記事を使用してください:

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

13

Certificate Master を使用して証明書を手動発行する、または CSR に署名する

これは 任意の 手順です。

FQDN の一覧に基づいて TLS サーバー証明書を発行する方法、または Certificate Master コンポーネントを使用して任意の CSR に署名する方法については、以下のリンクを参照してください。

Certificate Master

14

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

これは 任意の 手順です。

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

Enrollment REST API

15

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

これは 任意の 手順です。

既定では、SCEPman は Azure リソースに対してロックを適用しません。リソース ロックを使用し、設定したい場合は、以下の一覧に各 SCEPman リソースに適用可能なロックの種類を示します。

• Key Vault: Soft Delete と Purge Protection により、既に誤削除に対する保護が提供されています。SCEPman は CA キー作成後にリソースを変更しないため、 ReadOnlyLock は技術的には可能です。

• Storage Account: のみ DeleteLock が可能です。SCEPman は証明書情報をテーブルに書き込む必要があるためです。Storage Account が誤って削除されると、すでに発行された証明書に関する情報を失います。

• App Services: A ReadOnlyLock は理論上は可能ですが、SCEPman の構成を変更するたびに削除する必要があります。削除された App Service は簡単に再インストールできますが、既定の構成しか持たないため、すべての手動変更を再設定する必要があります。 DeleteLock および ReadOnlyLock の組み合わせは、このリスクの軽減に役立ちます。

• Log Analytics Workspace: A DeleteLock は技術的には可能ですが、保持期間中に収集されたログを失うだけであり、SCEPman サービスの可用性には影響しません。

• その他の Azure リソース: これらはデータを保存せず、情報を失うことなく再作成できます。 DeleteLock および ReadOnlyLock はそれらの一部に有用な場合があります。いくつかは、上記の中核サービスのいずれかに依存しているため、そもそも削除できません。