拡張ガイド
命名規則、冗長化、自動スケーリングなどの高度な要件を備えたエンタープライズ向け環境に SCEPman を導入するための全手順を案内します。
SCEPman Enterprise Edition のみ
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 に生成して保存します。
Storage Account
SCEPman の Certificate Master コンポーネントが失効目的で証明書属性を保存するために使用するストレージ プラットフォーム。 任意:
"App Service" は、手動更新が構成されている場合、blob storage URI から成果物を読み込みます。
Log Analytics Workspace
集中管理されたクラウドベースのログ保存先です。"App Service" はすべてを保存します
プラットフォーム ログとメトリクスをこのワークスペースに保存します。 v3.0 以降、SCEPman は Microsoft の Log Ingestion API を使用して Log Analytics Workspace にログを書き込みます。
さらに、Private Endpoint を使用している場合は、 追加で 7 つの Azure リソースがあります。
仮想ネットワーク
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 テンプレート
または代わりに Terraform スクリプト:
デプロイ後の手順を実行する（権限の割り当て）
これは 必須の 手順です。
SCEPman のすべてのコンポーネントを正しく連携させるには、いくつかの権限を割り当てる必要があります。関連する接続を確立するため、次の手順に従ってください:
Certificate Master の権限を追加する
これは 必須の の手順 Enterprise Edition のお客様向けです。 Community Edition のユーザーはこの手順を省略できます。
Certificate Master は Enterprise Edition 管理者が証明書を手動で生成および失効できる機能です。Certificate Master へのアクセスを許可するには、次の手順に従ってください。
カスタム ドメインと SSL 証明書を構成する
これは 推奨の 手順です。ただし、 この手順を省略 してください。ジオ冗長性を実装する場合は。
SCEPman を独自ドメインで利用できるようにするには、 カスタム ドメイン を App Service に作成する必要があります。
手動更新
既定では、SCEPman は 更新に対して常に最新を維持する アプローチを採用しています。SCEPman の更新を完全に制御する必要がある場合は、次のガイドの「 デプロイ スロットの構成.
ヘルス チェック アラートを構成する
これは 推奨の 手順です。
SCEPman App Service が応答しなくなった場合に管理者へ通知するよう、ヘルス チェックを構成できます。
インストール時にヘルス チェックは自動的に追加されますが、アラートは手動で構成する必要があります。
SCEPman に十分なリソースがあることを確認する
これは 必須の 手順です。
SCEPman を本番環境に移行したら、十分な計算能力があることを確認してください。そのため、Azure のサイジング ガイドを確認し、必要であれば App Service Plan のティアをアップグレードしてください。これは PoC または試用フェーズの後まで延期してもかまいません。
自動スケーリングを構成する
SCEPman ソリューションには 2 つの異なるタスクと性能要件があります。 1 つ目のタスクは証明書発行プロセスです。SCEPman ソリューションの構成後、すべてのデバイス（ユーザー証明書および/またはデバイス証明書）に証明書をデプロイする必要がありますが、これは 1 回限りの作業であり、初回デプロイ後に発生するのは新しいデバイスが登録されたとき、または証明書の更新が必要なときだけです。そのような状況では、SCEPman は SCEP 要求のピークに直面します。
2 つ目のタスクは証明書の検証です。デバイスに証明書をデプロイした後は、それらの証明書を使用するたびに検証する必要があります。証明書ベースの認証ごとに、クライアント、ゲートウェイ、または RADIUS システム（使用するものによります）が OCSP 要求を SCEPman App Service に送信します。これにより、App Service には継続的な要求負荷が発生します。
最適なパフォーマンスを確保し、コストにも配慮するため、App Service の自動スケーリング機能を設定することを推奨します。この機能により、アプリケーションはメトリックに基づいてスケールアウト/スケールインできます。
ジオ冗長性を構成する
SCEPman にジオ冗長なインスタンスを構成すると、複数の 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: ソフト削除とパージ保護によって、誤削除に対する保護はすでに提供されています。SCEPman は CA キー作成後にリソースを変更しないため、 ReadOnlyLock は技術的には可能です。
Storage Account: のみ DeleteLock が可能です。SCEPman は証明書情報をテーブルに書き込む必要があるためです。Storage Account が誤って削除されると、すでに発行された証明書の情報が失われます。
App Services: 1つの ReadOnlyLock ロックは理論上可能ですが、SCEPman の構成を変更するたびに削除する必要があります。削除された App Service は簡単に再インストールできますが、既定の構成しか持たないため、すべての手動変更を手動で再構成し直す必要があります。 DeleteLock および ReadOnlyLock がこのリスクの軽減に役立ちます。
Log Analytics Workspace: 1つの DeleteLock は技術的には可能ですが、失うのは保持期間中に収集されたログのみであり、SCEPman サービスの可用性には影響しません。
その他の Azure リソース: ロックは DeleteLock および ReadOnlyLock 一部のものでは有用です。上記のコア サービスのいずれかに依存しているため、まったく削除できないものもあります。
最終更新
役に立ちましたか？