# KCMから接続をインポート

## 変換手順 <a href="#conversion-process" id="conversion-process"></a>

この手順では、PythonスクリプトでKeeperコネクションマネージャー (KCM) のデータベースへ接続し、接続および接続グループをエクスポートしたうえで、既存のPAMプロジェクト向けの有効なJSONテンプレートへ変換します。

1. Pythonスクリプトは [こちら](https://github.com/Keeper-Security/Commander/tree/master/examples/pam-kcm-import)から入手できます。`kcm_export.py` と `KCM_mappings.json` の両方をダウンロードしてください。
2. `kcm_export.py` スクリプトは、KCMデータベース (ローカルまたはリモート) に接続し、接続および接続グループのデータを取得します。
3. 取得したデータは、`KCM_mappings.json` 内のマッピング辞書を用いて、PAMプロジェクトのJSONテンプレートに適合するパラメーターへ変換されます。
4. 接続グループは共有フォルダまたはネストされたフォルダとしてマッピングされます。詳細は[接続グループのモデリング](#connection-group-modelling)をご参照ください。
5. 変換が完了したら、PAM Project Extendコマンドを実行する前に、生成された共有フォルダをKeeperのゲートウェイアプリケーションに追加できます。\
   最終的なJSONファイルには、作成する共有フォルダの一覧に加え、動的トークンを含むと判定された接続名も含まれます。

### KCMデータベースへの接続を許可する <a href="#allowing-connections-to-the-kcm-database" id="allowing-connections-to-the-kcm-database"></a>

PythonスクリプトがKCMデータベースに接続するには、データベース側でポートを開放しておく必要があります。

### KeeperコネクションマネージャーのAuto-Dockerインストールの場合

Auto-Dockerインストールでは、`docker-compose.yml` は `/etc/kcm-setup` にあります。以下のとおり編集します。

```
sudo nano /etc/kcm-setup/docker-compose.yml
```

{% tabs %}
{% tab title="MySQL" %}

```yaml
db:
        image: keeper/guacamole-db-mysql:2
        restart: unless-stopped 
        environment:
            ACCEPT EULA: "Y"
            GUACAMOLE_DATABASE: "guacamole_db"
            GUACAMOLE_USERNAME: "guacamole_user"
            GUACAMOLE_PASSWORD: "XXXXXXXXXXXXXXXXXXXXXXXXX"
            GUACAMOLE_ADMIN_PASSWORD: "XXXXXXXXXXXXXXXXXXXXXXXXX"
            MYSQL_ROOT_PASSWORD: "XXXXXXXXXXXXXXXXXXXXXXXXXXXXXX"
        ports:
            - "3306:3306"            
```

{% endtab %}

{% tab title="Postgresql" %}

```yaml
db:
        image: keeper/guacamole-db-postgres:2
        restart: unless-stopped 
        environment:
            ACCEPT EULA: "Y"
            GUACAMOLE_DATABASE: "guacamole_db"
            GUACAMOLE_USERNAME: "guacamole_user"
            GUACAMOLE_PASSWORD: "XXXXXXXXXXXXXXXXXXXXXXXXX"
            GUACAMOLE_ADMIN_PASSWORD: "XXXXXXXXXXXXXXXXXXXXXXXXX"
            POSTGRES_PASSWORD: "XXXXXXXXXXXXXXXXXXXXXXXXXXXXXX"
        ports:
            - "5432:5432"            
```

{% endtab %}
{% endtabs %}

続いて、変更を反映します。

```
sudo ./kcm-setup.run apply
```

任意ですが、root以外のユーザーからPythonスクリプトを実行する場合は、Pythonが `docker-compose.yml` を読めるよう、ファイルの読み取り権限を変更する必要があります。

```
sudo chmod 644 /etc/kcm-setup/docker-compose.yml
```

### Docker Composeインストールの場合

Docker Composeで構築した場合も、上記と同じ内容で `docker-compose.yml` を更新したうえで、Dockerコンテナを再起動します。

```
docker compose up -d
```

#### 外部のPostgreSQLデータベースを使用する場合 <a href="#for-an-external-postgresql-database" id="for-an-external-postgresql-database"></a>

KCMホストがリモートデータベースに接続されている場合は、すでにポートが開いていることが多いですが、PostgreSQLでは `pg_hba.conf` で許可された接続元からしかアクセスできません。スクリプトを実行するホストが `pg_hba.conf` の許可対象に含まれていることを確認してください。

## モジュールのインストールとスクリプトの実行 <a href="#installing-modules-and-running-the-script" id="installing-modules-and-running-the-script"></a>

`kcm_export.py` および `KCM_mappings.json` と同じディレクトリで、Pythonの仮想環境を作成して有効化します。

{% tabs %}
{% tab title="Linux" %}

```
sudo apt install python3-venv
python3 -m venv venv
source venv/bin/activate
```

{% endtab %}

{% tab title="Windows" %}

```
python -m venv venv
venv\Scripts\activate
```

{% endtab %}
{% endtabs %}

続いて、スクリプトに必要なPythonモジュールをインストールします。

{% tabs %}
{% tab title="MySQL" %}

```
pip install pyYAML
pip install mysql-connector

pip install rich
```

{% endtab %}

{% tab title="PostgreSQL" %}

```
pip install pyYAML
pip install psycopg2-binary

pip install rich
```

{% endtab %}
{% endtabs %}

* `pyYAML` モジュールは `docker-compose.yml` を読み取るために使用します。
* `mysql-connector` / `psycopg2-binary` モジュールはデータベース接続に使用します。
* `rich` モジュールは、コンソール出力の整形と可読性向上にのみ使われます。省略可能ですが、使わない場合は `kcm_export.py` から該当する `import` 文を削除してください。

最後に、スクリプトを実行します。

```
python3 kcm_export.py
```

## スクリプトのCLI手順 <a href="#script-cli-process" id="script-cli-process"></a>

スクリプトは、CLI上のプロンプトに従って対話形式で進みます。

* 最初のプロンプトでは、接続先のデータベース種別を入力します。

<figure><img src="/files/zTS248KQP8lkjyMUxftO" alt="PAM KCM import - database prompt" width="563"><figcaption></figcaption></figure>

* 2番目のプロンプトでは、`docker-compose.yml` がローカルに保存されている場合は `1` を選択し、続けてファイルの場所を入力します。\
  データベースがリモートで、`docker-compose.yml` がローカル端末にない場合は、実行前に `kcm_export.py` に接続情報を直接記述し、`2` を選択します。

<figure><img src="/files/lrx10x8AnxNyiHISvLWh" alt="PAM KCM Import - Database connection prompt" width="563"><figcaption></figcaption></figure>

* 続いて、接続グループの構造を選択するプロンプトが表示されます。詳細は[接続グループのモデリング](#connection-group-modelling)をご参照ください。

<figure><img src="/files/Up9VGvSHf0Wmvvx9y3qv" alt="PAM KCM Import - Connection group structure prompt" width="563"><figcaption></figcaption></figure>

* (任意) 最後に、変換と併せてテンプレートJSONファイルを使用するかどうかを選択するプロンプトが表示されます。すべてのリソース/ユーザーに共通のパラメーターを一括で与えたい場合にのみ、テンプレートJSONが必要になります。

<figure><img src="/files/3QzFtpHjc56oxMCYfxi0" alt="PAM KCM Import - template prompt" width="563"><figcaption></figcaption></figure>

テンプレートファイルには、以下の内容が含まれます。

* `pamDirectory` リソースとそのユーザー。これらはテンプレート内にハードコードされています。
* `pamMachine` リソースとそのユーザー。変換スクリプトのテンプレートとなるリソースおよびユーザーとして使われます。KCMの値で直接上書きされないフィールドは、変換後のオブジェクトへ取り込まれます。

### Commanderでのファイルのインポート <a href="#importing-the-file-with-commander" id="importing-the-file-with-commander"></a>

最後のプロンプトの後、作業ディレクトリに `pam_import.json` が作成されます。このファイルは、コマンダーでPAM Project Extendコマンドを使ってインポートできます (手順は[ガイド](/keeperpam/jp/privileged-access-manager/references/importing-pam-resources/adding-pam-resources-to-an-existing-model.md)をご参照ください)。

```
pam project extend -c <pam_configuration_uid> -f path/to/pam_import.json
```

{% hint style="info" %}
接続グループから生成された共有フォルダを、忘れずに追加してください。

その一覧はCLIに出力され、`pam_import.json` にも追記されます。
{% endhint %}

KCMの接続に動的トークンが含まれる場合、ファイル内の `logged_records` に記録されます。詳細は[KCMマッピングとlogged\_records](#kcm-mappings-and-logged-records)をご参照ください。

## 接続グループのモデリング <a href="#connection-group-modelling" id="connection-group-modelling"></a>

### フォルダパスの生成 <a href="#folder-path-generation" id="folder-path-generation"></a>

接続グループは、JSONテンプレート上のフォルダパスとしてモデル化されます。

KCMでは接続にユーザー認証情報が含まれますが、PAMでは通常、認証情報とリソースは別々の共有フォルダに分かれます。リソースとユーザーは別フォルダパスへ振り分けられ、ルートには `KCM Resources -` および `KCM Users -` のプレフィックスが付与されます。

たとえば、KCMで以下のフォルダパスに接続があるとします。

* Infra / Site 01 / Windows RDP

リソースレコードとユーザーレコードには、それぞれ以下のフォルダパスが割り当てられます。

* KCM Resources - Infra / Site 01 / KCM Resource - Windows RDP
* KCM Resources - Infra / Site 01 / KCM User - Windows RDP

ルートフォルダおよびリソースとユーザーのタイトルにはプレフィックスが付きますが、ネストされたフォルダ名はそのまま保持されます。

### フォルダ構造 <a href="#folder-structure" id="folder-structure"></a>

前述の選択式プロンプトで示したとおり、KCMの接続グループをフォルダパスへ読み替える方法が3つ用意されています。

* **KSM構成ベース**

フォルダパスは、概ねKCMの接続グループ構造に沿います。ルートフォルダは共有フォルダ、ネストされたフォルダは個人用フォルダとして扱われます。ただし、接続グループにKSMサービス構成が含まれる場合は、ルートフォルダとして設定されます。

KSMサービス構成を含む接続グループは切り分け、細かい単位で共有できるようルート共有フォルダとして扱う、という前提に立っています。

* **ネストをそのまま保持**

フォルダパスは、KCMの接続グループ構造に完全に一致します。

* **フラット**

ネストは解消され、KCMの各接続グループはルート共有フォルダとしてモデル化されます。

## KCMマッピングとlogged\_records <a href="#kcm-mappings-and-logged-records" id="kcm-mappings-and-logged-records"></a>

スクリプトが出力するJSONファイルには、`logged_records` のリストが含まれる場合があります。動的トークンを含む接続はこのリストに載りますが、特定のパラメーターに応じて他のレコードをログへ残すこともできます。

スクリプトは `KCM_mappings.json` と併せて動作します。このファイルは、KCMのパラメーターとPAMプロジェクトのパラメーターの対応を定義する辞書です。非対応のパラメーターは `null` に、PAMに適用されないパラメーターは `ignore` にマッピングします。パラメーターを `log` にマッピングすると、該当する値を持つ接続が `logged_records` の出力に追加されます。

インポート後にパラメーターを洗い出したいときの手がかりになります。

## SFTPの扱い <a href="#sftp-handling" id="sftp-handling"></a>

KCMでは、SFTPのパラメーターにホストと認証情報が含まれます。PAMでは扱いが異なり、`pamMachine` / `pamUser` レコードを参照できます。

接続にSFTPパラメーターが含まれる場合、ポート22の新しい `pamMachine` および `pamUser` が自動作成され、当該接続のフォルダから1階層下の `SFTP` というラベルのフォルダに格納されます。

## デバッグ <a href="#debugging" id="debugging"></a>

`kcm_export.py` の先頭にある `DEBUG` 定数を `True` に変更すると、デバッグを有効にできます。


---

# Agent Instructions: Querying This Documentation

If you need additional information that is not directly available in this page, you can query the documentation dynamically by asking a question.

Perform an HTTP GET request on the current page URL with the `ask` query parameter:

```
GET https://docs.keeper.io/keeperpam/jp/privileged-access-manager/references/importing-pam-resources/import-connections-from-kcm.md?ask=<question>
```

The question should be specific, self-contained, and written in natural language.
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.