拡張ガイド

circle-exclamation

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

Azure デプロイ

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

前提条件

必須

任意

Azure リソース概要

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

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

構成手順

1

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

circle-exclamation

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

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

Enterprise デプロイchevron-right

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

Terraform デプロイchevron-right

2

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

circle-exclamation

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

Managed Identitieschevron-right

3

Certificate Master の権限を追加する

circle-check

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

Certificate Master RBACchevron-right

4

ルート証明書の作成

circle-exclamation

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

ルート CAchevron-right

5

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

circle-check

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

カスタム ドメインchevron-right

6

手動更新

circle-info

これは 任意の 手順です。

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

更新戦略chevron-right

7

Application Insights をデプロイする

circle-check

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

Application Insightschevron-right

8

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

circle-check

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

ヘルス チェックchevron-right

9

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

circle-exclamation

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

App Service のサイズ設定chevron-right

10

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

circle-info

これは 任意の 手順です。

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

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

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

自動スケーリングchevron-right

11

地理冗長性を構成する

circle-info

これは 任意の 手順です。

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

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

ジオ冗長chevron-right

12

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

circle-check

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

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

Microsoft Intunechevron-rightJamf Prochevron-rightその他の MDM ソリューションchevron-right

13

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

circle-info

これは 任意の 手順です。

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

Certificate Masterchevron-right

14

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

circle-info

これは 任意の 手順です。

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

Enrollment REST APIchevron-right

15

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

circle-info

これは 任意の 手順です。

既定では、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 はそれらの一部に有用な場合があります。いくつかは、上記の中核サービスのいずれかに依存しているため、そもそも削除できません。

最終更新

役に立ちましたか?