> For the complete documentation index, see [llms.txt](https://docs.scepman.com/llms.txt). Markdown versions of documentation pages are available by appending `.md` to page URLs; this page is available as [Markdown](https://docs.scepman.com/ja/scepman-no/deployment-guides/enterprise-guide-1.md).
# 拡張ガイド
命名規則、冗長化、自動スケーリングなどの高度な要件を備えたエンタープライズ向け環境に SCEPman を導入するための全手順を案内します。
{% hint style="warning" %}
SCEPman Enterprise Edition のみ
{% endhint %}
## Azure デプロイ
まず、要件とリソースの概要から始めましょう。\
有用な Azure リソース設計を計画する必要があることを念頭に置いてください。
### 前提条件
#### 必須
* [ ] Azure リソースの命名規則。
* [ ] Azure サブスクリプション（そのサブスクリプションに対する少なくとも Contributor 権限）。
* [ ] Azure の所有者権限（少なくともリソース グループ レベル）。
* [ ] Microsoft Entra ID（Azure AD）の「グローバル管理者」（Graph API へのアクセスに同意）。
* [ ] Azure ポリシーを必ず定義してください [SCEPman の要件に従って](/ja/sono/security-faq.md#azure-cis) （例: TLS を強制しない）。
* [ ] パブリック ドメイン CNAME（*scepman.yourdomain.com*）、ジオ冗長性を使用する場合のみ。
* [ ] SSL 証明書（または [App Service 管理証明書](https://docs.microsoft.com/en-us/azure/app-service/configure-ssl-certificate#create-a-free-certificate-preview)）、ジオ冗長性を使用する場合のみ。
* [ ] SCEPman Enterprise Edition ライセンス キー。
#### 任意
* [ ] パブリック ドメイン CNAME（*scepman.yourdomain.com*）、カスタム ドメインを使用する場合のみ。
* [ ] SSL（ワイルドカード）証明書（または [App Service 管理証明書](https://docs.microsoft.com/en-us/azure/app-service/configure-ssl-certificate#create-a-free-certificate-preview)）、カスタム ドメインを使用する場合のみ。
### 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 リソースがあります。](/ja/azure-gou-cheng/private-endpoints.md#azure-resources-used-for-private-endpoints)
| 種類 | 説明 |
|---|
| 仮想ネットワーク | 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 に接続します。 |
## 構成手順
{% stepper %}
{% step %}
### SCEPman ベース サービスをデプロイする
{% hint style="warning" %}
これは **必須の** 手順です。
{% endhint %}
デプロイする際に使用する **Windows** または **Linux** App Service Plan を選択してください。どちらのデプロイ方法でも、オペレーティング システムを選択できます。
デプロイを開始するには、次のいずれかを利用したセットアップ手順に従う必要があります。 **ARM テンプレート**
{% content-ref url="/pages/514b43b3dacbc9f3f011125d8f806184425e36ce" %}
[エンタープライズ展開](/ja/scepman-no/deployment-options/enterprise-deployment.md)
{% endcontent-ref %}
または代わりに **Terraform** スクリプト:
{% content-ref url="/pages/49f854f416a0c8f1c227a035f9f32c7c52e98185" %}
[Terraform 展開](/ja/scepman-no/deployment-options/terraform-deployment.md)
{% endcontent-ref %}
{% endstep %}
{% step %}
### デプロイ後の手順を実行する（権限の割り当て）
{% hint style="warning" %}
これは **必須の** 手順です。
{% endhint %}
SCEPman のすべてのコンポーネントを正しく連携させるには、いくつかの権限を割り当てる必要があります。関連する接続を確立するため、次の手順に従ってください:
{% content-ref url="/pages/c9baa8d4cb5c43880feb830c2ec1c10083883fa7" %}
[マネージド ID](/ja/scepman-no/permissions/post-installation-config.md)
{% endcontent-ref %}
{% endstep %}
{% step %}
### Certificate Master の権限を追加する
{% hint style="success" %}
これは **必須の** の手順 **Enterprise** **Edition** のお客様向けです。 **Community Edition** のユーザーはこの手順を省略できます。
{% endhint %}
Certificate Master は **Enterprise Edition** 管理者が証明書を手動で生成および失効できる機能です。Certificate Master へのアクセスを許可するには、次の手順に従ってください。
{% content-ref url="/pages/89fcf39f72fa6a350a1fcf569e8e1487783f9f0e" %}
[証明書マスター RBAC](/ja/scepman-gou-cheng/rbac.md)
{% endcontent-ref %}
{% endstep %}
{% step %}
### ルート証明書を作成する
{% hint style="warning" %}
これは **必須の** 手順です。
{% endhint %}
デプロイと権限の割り当てが完了したら、SCEPman のルート証明書を作成する必要があります:
{% content-ref url="/pages/0ebdf2507a832e59c0cf5125ffda7b54f6043866" %}
[ルート CA](/ja/scepman-no/first-run-root-cert.md)
{% endcontent-ref %}
{% endstep %}
{% step %}
### カスタム ドメインと SSL 証明書を構成する
{% hint style="success" %}
これは **推奨の** 手順です。ただし、 **この手順を省略** してください。ジオ冗長性を実装する場合は。
{% endhint %}
SCEPman を独自ドメインで利用できるようにするには、 **カスタム ドメイン** を **App Service に作成する必要があります。**
{% content-ref url="/pages/8eb47ea387d89933dddb8698281a8acb2f7a1af7" %}
[カスタム ドメイン](/ja/azure-gou-cheng/custom-domain.md)
{% endcontent-ref %}
{% endstep %}
{% step %}
### 手動更新
{% hint style="info" %}
これは **任意の** 手順です。
{% endhint %}
既定では、SCEPman は [更新に対して常に最新を維持する](/ja/azure-gou-cheng/update-strategy.md#evergreen-approach) アプローチを採用しています。SCEPman の更新を完全に制御する必要がある場合は、次のガイドの「 **デプロイ スロットの構成**.
{% content-ref url="/pages/d11979f767e4900580bf70531c13b3211e25501f" %}
[更新戦略](/ja/azure-gou-cheng/update-strategy.md)
{% endcontent-ref %}
{% endstep %}
{% step %}
### ヘルス チェック アラートを構成する
{% hint style="success" %}
これは **推奨の** 手順です。
{% endhint %}
SCEPman App Service が応答しなくなった場合に管理者へ通知するよう、ヘルス チェックを構成できます。
インストール時にヘルス チェックは自動的に追加されますが、アラートは手動で構成する必要があります。
{% content-ref url="/pages/32ff1ed3cf0a5e6f9fe077cdd74cacb7a2488410" %}
[ヘルスチェック](/ja/azure-gou-cheng/health-check.md)
{% endcontent-ref %}
{% endstep %}
{% step %}
### SCEPman に十分なリソースがあることを確認する
{% hint style="warning" %}
これは **必須の** 手順です。
{% endhint %}
SCEPman を本番環境に移行したら、十分な計算能力があることを確認してください。そのため、Azure のサイジング ガイドを確認し、必要であれば App Service Plan のティアをアップグレードしてください。これは PoC または試用フェーズの後まで延期してもかまいません。
{% content-ref url="/pages/7653b5876336dbccf48b2ad0699905af5aad267b" %}
[App Service サイジング](/ja/azure-gou-cheng/azure-sizing.md)
{% endcontent-ref %}
{% endstep %}
{% step %}
### 自動スケーリングを構成する
{% hint style="info" %}
これは **任意の** 手順です。
{% endhint %}
SCEPman ソリューションには 2 つの異なるタスクと性能要件があります。\
1 つ目のタスクは証明書発行プロセスです。SCEPman ソリューションの構成後、すべてのデバイス（ユーザー証明書および/またはデバイス証明書）に証明書をデプロイする必要がありますが、これは 1 回限りの作業であり、初回デプロイ後に発生するのは新しいデバイスが登録されたとき、または証明書の更新が必要なときだけです。そのような状況では、SCEPman は SCEP 要求のピークに直面します。
2 つ目のタスクは証明書の検証です。デバイスに証明書をデプロイした後は、それらの証明書を使用するたびに検証する必要があります。証明書ベースの認証ごとに、クライアント、ゲートウェイ、または RADIUS システム（使用するものによります）が OCSP 要求を SCEPman App Service に送信します。これにより、App Service には継続的な要求負荷が発生します。
最適なパフォーマンスを確保し、コストにも配慮するため、App Service の自動スケーリング機能を設定することを推奨します。この機能により、アプリケーションはメトリックに基づいてスケールアウト/スケールインできます。
{% content-ref url="/pages/b062e1e788c083e1db92c464a35b0a1e95820657" %}
[自動スケーリング](/ja/azure-gou-cheng/azure-sizing/autoscaling.md)
{% endcontent-ref %}
{% endstep %}
{% step %}
### ジオ冗長性を構成する
{% hint style="info" %}
これは **任意の** 手順です。
{% endhint %}
SCEPman にジオ冗長なインスタンスを構成すると、複数の Azure リージョンにワークロードを分散できるため、サービスの可用性と耐障害性を高めることができます。
ただし、この構成では追加のリソースとデータ複製が必要になるため、Azure のコストが増加する可能性があることに注意してください。Microsoft は Azure App Services に対して 99.95% の SLA を提供しており、ほとんどのシナリオではこれで十分です。
{% content-ref url="/pages/a25360d8b5e68a413fa1636f1a7b741651747937" %}
[地理冗長性](/ja/azure-gou-cheng/geo-redundancy.md)
{% endcontent-ref %}
{% endstep %}
{% step %}
### MDM デプロイ プロファイルを構成する
{% hint style="success" %}
これは **推奨の** 手順です。
{% endhint %}
以上の手順が完了すると、SCEPman は正常に動作する状態になり、デバイスに証明書をデプロイできるようになります。
お使いの MDM ソリューションで証明書をデプロイするには、以下の記事の 1 つ以上を参照してください:
{% content-ref url="/pages/d707fc5c0d1b5e571123c01e0b8435ced93eec79" %}
[Microsoft Intune](/ja/zheng-ming-shu-guan-li/microsoft-intune.md)
{% endcontent-ref %}
{% content-ref url="/pages/2776ebdbcac8bdd11e7e51f36b87d22571d17925" %}
[Jamf Pro](/ja/zheng-ming-shu-guan-li/jamf.md)
{% endcontent-ref %}
{% content-ref url="/pages/11b60abb2a67558c45dc098171dd45154598686c" %}
[その他の MDM ソリューション](/ja/zheng-ming-shu-guan-li/static-certificates.md)
{% endcontent-ref %}
{% endstep %}
{% step %}
### Certificate Master を使用して証明書を手動で発行する、または CSR に署名する
{% hint style="info" %}
これは **任意の** 手順です。
{% endhint %}
以下のリンクを参照して、FQDN の一覧に基づいて TLS サーバー証明書を発行する方法、または Certificate Master コンポーネントを使用して任意の CSR に署名する方法を確認してください。
{% content-ref url="/pages/13fdf762be2175fdd2546ac4ec8454a1421e7523" %}
[証明書マスター](/ja/zheng-ming-shu-guan-li/certificate-master.md)
{% endcontent-ref %}
{% endstep %}
{% step %}
### Enrollment REST API を使用して証明書を発行する
{% hint style="info" %}
これは **任意の** 手順です。
{% endhint %}
SCEPman には証明書を登録するための REST API があります。これは SCEP 形式の認証を必要とする SCEP エンドポイントの代替であり、REST API は認証に Microsoft Identities を使用します。プロトコルも SCEP よりはるかにシンプルです。
{% content-ref url="/pages/4201a583ebbce39728e36841429bb7a0f3873e99" %}
[登録用 REST API](/ja/zheng-ming-shu-guan-li/api-certificates.md)
{% endcontent-ref %}
{% endstep %}
{% step %}
### SCEPman の Azure リソースにロックを作成する
{% hint style="info" %}
これは **任意の** 手順です。
{% endhint %}
既定では、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** 一部のものでは有用です。上記のコア サービスのいずれかに依存しているため、まったく削除できないものもあります。
{% endstep %}
{% endstepper %}
---
# Agent Instructions
This documentation is published with GitBook. GitBook is the documentation platform designed so that both humans and AI agents can read, navigate, and reason over technical content effectively. Learn more at gitbook.com.
## Querying This Documentation
If you need additional information that is not directly available in this page, you can query the documentation by asking a question.
Perform an HTTP GET request on the following URL with the `ask` and `goal` query parameters:
```
GET https://docs.scepman.com/ja/scepman-no/deployment-guides/enterprise-guide-1.md?ask=&goal=
```
`ask` is the immediate question: it should be specific, self-contained, and written in natural language.
`goal` is what the user is ultimately trying to achieve, the reason they need the answer. Sharing it helps GitBook give you a better, more relevant answer. A goal is most helpful when it describes the outcome the user wants rather than restating the question. For example, with `ask=how do I create an API token`, a goal like `automate deployments from our CI pipeline` lets GitBook tailor the answer to that use case.
The response will contain a direct answer to the question and relevant excerpts and sources from the documentation.
Use this mechanism when the answer is not explicitly present in the current page, you need clarification or additional context, or you want to retrieve related documentation sections.