拡張ガイド
SCEPman Enterprise Edition のみ
これにより、命名規則、冗長化、オートスケーリングなどの高度な要件を備えたエンタープライズ グレードの環境向けに SCEPman をデプロイするための全手順をご案内します。
Azure デプロイ
要件とリソース概要から始めましょう。 実用的な Azure リソース設計を計画する必要があることに留意してください。
前提条件
必須
任意
Azure リソースの概要
本番環境には、以下のリソースを推奨します。
App Service (x2)
SCEPman Core と Cert Master アプリケーションを実行するための仮想 Azure 環境であり、CNAME、SSL 証明書、App Settings などのアプリケーション固有の設定を構成するための UI を提供します。
App Service プラン
「App Service(s)」用の仮想的なコンピューティング リソースと構成のセットです。
ここでは、価格レベルとリソースのスケーリングを構成できます。
Key Vault
シークレットと証明書を安全に保存するためのツールです。SCEPman アプリケーションは、ルート証明書を Key Vault に生成して保存します。
Application Insights
SCEPman アプリケーションと要求の洞察を得るための Application Performance Management (APM) ツールです。パフォーマンスの測定に必要で、サービス最適化に適しています。
Storage Account
SCEPman の Certificate Master コンポーネントが失効目的で証明書属性を保存するために使用する Storage Account です。 オプション:
手動更新が構成されている場合、"App Service" は blob ストレージ URI から成果物を読み込みます。
Log Analytics Workspace
中央集約型のクラウドベースのログ保存領域です。"App Service" はすべてを保存します
プラットフォームのログとメトリックをこのワークスペースに保存します。 v3.0 以降、SCEPman は Microsoft の Log Ingestion API を使用して Log Analytics Workspace にログを書き込みます。
さらに、Private Endpoints を使用している場合は、 追加の Azure リソースを 7 つ。
仮想ネットワーク
SCEPman App Services、Key Vault、および Storage Account は、この VNET を介して接続します。
プライベート エンドポイント (×2)
Key Vault 用が 1 つ、Storage Account 用が 1 つです。これにより、VNET 経由でアクセスできるようになります。
プライベート DNS ゾーン (×2)
Key Vault 用が 1 つ、Storage Account 用が 1 つです。どちらも VNET 内に内部 IP アドレスを持ち、それぞれのプライベート DNS ゾーンに名前があります。
ネットワーク インターフェイス (×2)
Key Vault 用が 1 つ、Storage Account 用が 1 つです。プライベート エンドポイントを VNET に接続します。
構成手順
SCEPman 基本サービスをデプロイ
これは 必須の 手順です。
どちらの方法でデプロイするかを選択してください。 Windows または Linux App Service Plan。どちらのデプロイ方法でも、オペレーティング システムを選択できます。
デプロイを開始するには、ARM Template を利用する、または代わりに Terraform スクリプトを使用したセットアップ手順に従う必要があります。 ARM Template
または代わりに Terraform スクリプト:
デプロイ後の手順を実施する（権限の割り当て）
これは 必須の 手順です。
SCEPman のすべてのコンポーネントを適切に連携するには、いくつかの権限を割り当てる必要があります。関連する接続を確立するため、以下の手順に従ってください:
Certificate Master の権限を追加
これは 必須の の手順は Enterprise Edition のお客様向けです。 Community Edition ユーザーはこの手順をスキップできます。
Certificate Master は Enterprise Edition 管理者が証明書を手動で生成および失効できる機能です。Certificate Master へのアクセスを提供するには、以下の手順に従ってください。
カスタム ドメインと SSL 証明書を構成
これは 推奨されます 手順。ただし、 スキップ してください。geo 冗長性を実装する場合は、この手順をスキップします。
SCEPman を特定のドメインで利用できるようにするには、 Custom Domain を App Service に作成する必要があります。
手動更新
既定では、SCEPman は 常に最新を維持するアプローチ を更新に採用しています。SCEPman の更新を完全に制御する必要がある場合は、以下のガイドのセクションで説明されているようにデプロイ スロットを構成してください。 デプロイ スロットの構成.
Application Insights をデプロイ
これは 推奨されます 手順です。
Application Insights を使用すると、App Service のパフォーマンスの概要を把握し、SCEPman の要求処理をより深く把握できます。App Service の監視、保守、最適化のために、Application Insights を常に構成することをお勧めします。
SCEPman に十分なリソースがあることを確認してください
これは 必須の 手順です。
SCEPman を本番環境に移行したら、十分な計算リソースが備わっていることを確認してください。そのため、Azure サイジング ガイドを確認し、必要であれば App Service プランの階層をアップグレードしてください。この作業は PoC または試用期間の後まで延期しても構いません。
オートスケーリングを構成する
SCEPman ソリューションには、2 つの異なるタスクとパフォーマンス要件があります。 1 つ目のタスクは証明書の発行プロセスです。SCEPman ソリューションの構成後、すべてのデバイス（ユーザー証明書および/またはデバイス証明書）に証明書を展開する必要がありますが、これは 1 回限りのタスクであり、初回展開後は、新しいデバイスが登録されたとき、または証明書の更新が必要になったときにのみ発生します。そのような状況では、SCEPman は SCEP 要求のピークに直面します。
2 つ目のタスクは証明書の検証です。デバイスに証明書を展開した後は、それらの証明書を使用するたびに検証する必要があります。証明書ベースの認証ごとに、クライアント、ゲートウェイ、または RADIUS システム（使用するものによります）が SCEPman App Service に OCSP 要求を送信します。これにより、App Service には恒常的な要求負荷が発生します。
最適化されたパフォーマンスを確保し、コストにも配慮するため、App Service のオートスケーリング機能を設定することを推奨します。この機能により、アプリケーションはメトリックに基づいてスケールアウトおよびスケールインできます。
geo 冗長性を構成する
SCEPman の geo 冗長インスタンスを構成すると、複数の Azure リージョンにワークロードを分散することで、サービスの可用性と耐障害性を向上できます。
ただし、この構成では追加リソースとデータのレプリケーションが必要になるため、Azure のコストが増加する可能性があることに注意してください。Microsoft は Azure App Services に対して 99.95% の SLA を提供しており、ほとんどのシナリオではこれで十分です。
MDM デプロイ プロファイルを構成
これは 推奨されます 手順です。
上記の手順が完了すると、SCEPman は正常に動作する実装となり、デバイスに証明書をデプロイできるようになります。
お使いの MDM ソリューションで証明書をデプロイするには、以下の記事を 1 つ以上ご利用ください:
Certificate Master を使用して証明書を手動発行する、または CSR に署名する
以下のリンクを参照して、FQDN の一覧に基づいて TLS サーバー証明書を発行する方法、または Certificate Master コンポーネントを使用して任意の CSR に署名する方法をご確認ください。
Enrollment REST API を使用して証明書を発行する
SCEPman には証明書を登録するための REST API があります。これは、SCEP 形式の認証を必要とする SCEP エンドポイントの代替であり、REST API は認証に Microsoft Identities を使用します。このプロトコルは SCEP よりもはるかに単純です。
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 一部のものには DeleteLock が有用な場合があります。いくつかは、上記のいずれかのコア サービスに依存しているため、そもそも削除できません。
最終更新
役に立ちましたか？