記事一覧に戻る

薬局ITインフラにWarpgateを導入:複数店舗のサーバーを安全に一元管理

(更新: 2026年3月21日)

はじめに

薬局チェーンのIT管理者にとって、複数店舗のサーバーを安全に管理することは大きな課題です。レセコン、在庫管理システム、電子薬歴など、各店舗には業務に不可欠なサーバーが稼働しています。しかし店舗が増えるほど、SSH鍵の管理やアクセス制御は煩雑になり、セキュリティリスクが高まります。

本記事では、オープンソースのセルフホスト型アクセス管理ツール Warpgate を薬局チェーンのITインフラに導入し、複数店舗のサーバーを安全に一元管理する方法を解説します。


薬局チェーンIT管理の課題

3〜10店舗規模の薬局チェーンでは、以下のような問題が発生しがちです。

SSH鍵管理がバラバラ

店舗ごとにサーバーが設置されている場合、SSH鍵の配布・更新が属人的になりがちです。「この店舗のサーバーには誰の鍵が入っているのか」を正確に把握できていないケースも珍しくありません。

退職者のアクセス削除が漏れる

IT担当が薬剤師と兼任であることが多い薬局では、退職者が出た際に全店舗のサーバーから該当する公開鍵やアカウントを確実に削除する運用が定着しにくい傾向にあります。1店舗でも漏れがあれば、それがセキュリティホールになります。

ベンダーへの一時アクセス付与

レセコンや電子薬歴の保守ベンダーに一時的なアクセスを付与する場面は頻繁にあります。しかし「とりあえず共有アカウントを渡す」運用では、誰がいつ何をしたか追跡できません。作業完了後にパスワードを変更し忘れるリスクもあります。

患者データという重い責任

薬局が扱うデータには、患者の氏名・生年月日・処方内容・病歴といった要配慮個人情報が含まれます。個人情報保護法や薬機法の観点からも、アクセス管理と監査証跡の整備は必須です。


Warpgateとは

Warpgate はオープンソースのセルフホスト型アクセス管理ツールです。SSH・HTTPS・MySQL・PostgreSQLのプロトコルに対応し、以下の特徴を持っています。

  • user:target@warpgate-host 形式でSSH接続(専用クライアント不要)
  • 2FA(TOTP)とOIDC SSO対応
  • セッション録画・コマンドレベル監査ログ
  • RBAC(ロールベースアクセス制御)
  • Docker / 単一バイナリでデプロイ可能

専用クライアントが不要という点が特に重要です。既存のSSHクライアントやMySQLクライアントがそのまま使えるため、現場の運用を大きく変えずに導入できます。


Warpgateで解決できること

一元的なアクセス制御(RBAC)

Warpgateでは「ロール」を定義し、各ユーザーにロールを割り当てます。例えば以下のようなロール設計が可能です。

ロール接続先用途
admin全店舗サーバー + DB本部IT管理者
store-manager自店舗サーバーのみ店舗責任者
vendor-receレセコンサーバーのみレセコン保守ベンダー
vendor-ehr電子薬歴サーバーのみ電子薬歴ベンダー

退職者が出た場合は、Warpgate上でアカウントを無効化するだけで全店舗へのアクセスが即座に遮断されます。各サーバーに個別にログインしてSSH鍵を削除する必要はありません。

SSO連携でスタッフのログイン統合

WarpgateはOIDC(OpenID Connect)に対応しているため、Google WorkspaceやMicrosoft Entra ID(旧Azure AD)と連携できます。薬局チェーンで既にこれらのサービスを利用していれば、スタッフは普段のアカウントでWarpgateにログインでき、パスワードの一元管理が実現します。

セッション録画で監査証跡

Warpgateのセッション録画機能は、SSH接続中のすべての入出力を記録します。これにより以下が可能になります。

  • ベンダー作業の事後確認
  • インシデント発生時の原因究明
  • 監査対応(いつ・誰が・何をしたかの証跡)

医療分野では「説明責任」が求められる場面が多く、セッション録画は単なるセキュリティ対策以上の価値を持ちます。

DB接続もWarpgate経由で保護

WarpgateはMySQL / PostgreSQLのプロキシとしても動作します。薬局の在庫管理DBや電子薬歴DBへの接続をWarpgate経由にすることで、DBアクセスにも認証・監査を適用できます。直接DBポートを公開する必要がなくなり、攻撃対象面が縮小します。


構成図

本部にWarpgateサーバーを設置し、各店舗とはTailscaleで接続する構成を示します。

graph TB
    subgraph HQ["🏢 本部"]
        WG["🔐 Warpgate<br/>Docker Container"]
        TS_HQ["Tailscale<br/>100.x.x.1"]
    end

    subgraph StoreA["🏥 A店舗"]
        SRV_A["レセコン<br/>在庫管理<br/>電子薬歴"]
        TS_A["Tailscale<br/>100.x.x.10"]
    end

    subgraph StoreB["🏥 B店舗"]
        SRV_B["レセコン<br/>在庫管理<br/>電子薬歴"]
        TS_B["Tailscale<br/>100.x.x.11"]
    end

    subgraph StoreC["🏥 C店舗"]
        SRV_C["レセコン<br/>在庫管理<br/>電子薬歴"]
        TS_C["Tailscale<br/>100.x.x.12"]
    end

    Admin["👤 IT管理者"] -->|SSH / HTTPS| WG
    Vendor["🔧 ベンダー"] -->|SSH| WG
    WG --- TS_HQ
    TS_HQ ---|Tailscale Mesh| TS_A
    TS_HQ ---|Tailscale Mesh| TS_B
    TS_HQ ---|Tailscale Mesh| TS_C
    TS_A --- SRV_A
    TS_B --- SRV_B
    TS_C --- SRV_C

この構成のポイントは以下の通りです。

  1. インターネットにSSHポートを公開しない — Tailscaleのメッシュ VPN内で通信が完結
  2. Warpgateが唯一のエントリポイント — 全アクセスがWarpgateを経由するため、制御と監査が確実
  3. 店舗側の設定が最小限 — TailscaleをインストールしてSSHサーバーを起動するだけ

Docker Composeでの構築例

本部サーバーにWarpgateをDocker Composeでデプロイする例です。

version: "3.8"

services:
  warpgate:
    image: ghcr.io/warp-tech/warpgate:latest
    container_name: warpgate
    restart: unless-stopped
    ports:
      - "2222:2222"   # SSH
      - "8888:8888"   # HTTPS (管理UI)
      - "33306:33306" # MySQL プロキシ
    volumes:
      - warpgate-data:/data
    environment:
      - TZ=Asia/Tokyo
    network_mode: host  # Tailscaleのネットワークにアクセスするため

volumes:
  warpgate-data:

初期セットアップ

# コンテナを起動(初回はセットアップウィザードが走る)
docker compose up -d

# ログで初期パスワードを確認
docker compose logs warpgate | grep "password"

初回起動時にセットアップウィザードが実行され、管理者アカウントが作成されます。その後、https://warpgate-host:8888 のWeb UIからターゲット(接続先サーバー)やユーザー、ロールを設定します。

ターゲットの登録例

Web UIまたは設定ファイルで、各店舗のサーバーをターゲットとして登録します。

# warpgate.yaml のターゲット定義例
targets:
  - name: store-a-server
    address: 100.x.x.10:22
    auth:
      type: ssh-key
    roles:
      - admin
      - store-a-staff

  - name: store-b-server
    address: 100.x.x.11:22
    auth:
      type: ssh-key
    roles:
      - admin
      - store-b-staff

  - name: store-a-db
    address: 100.x.x.10:3306
    type: mysql
    roles:
      - admin

接続方法

登録が完了したら、以下のようにSSH接続できます。

# user:target@warpgate-host の形式で接続
ssh admin:[email protected] -p 2222

MySQL接続も同様にWarpgate経由で行えます。

mysql -h 100.x.x.1 -P 33306 -u admin:store-a-db

セキュリティ強化のポイント

TOTP二要素認証の必須化

Warpgateでは全ユーザーにTOTP(Google Authenticator等)による二要素認証を義務付けることができます。薬局のシステムにアクセスする全員(社内スタッフ・ベンダー問わず)に2FAを強制することを推奨します。

ベンダーアクセスの時限制御

ベンダーへのアクセス付与は、作業予定日のみユーザーを有効化し、作業完了後に無効化する運用が理想です。Warpgate自体にスケジュール機能はありませんが、APIを利用してスクリプトで自動化できます。

# ベンダーアカウントの有効化(作業日の朝に実行)
curl -X PUT https://warpgate:8888/api/users/vendor-rece \
  -H "Authorization: Bearer $TOKEN" \
  -d '{"disabled": false}'

# 無効化(作業日の夕方に実行)
curl -X PUT https://warpgate:8888/api/users/vendor-rece \
  -H "Authorization: Bearer $TOKEN" \
  -d '{"disabled": true}'

ログの長期保存

セッション録画と監査ログは、外部のストレージやログ管理サービスにバックアップすることを推奨します。医療関連のデータアクセスログは、最低でも5年間の保存が望ましいとされています。

Tailscale ACLによるネットワーク分離

Tailscaleの ACL(Access Control List)を併用することで、ネットワークレベルでもアクセスを制限できます。

{
  "acls": [
    {
      "action": "accept",
      "src": ["tag:warpgate"],
      "dst": ["tag:pharmacy-server:22", "tag:pharmacy-server:3306"]
    }
  ]
}

これにより、Warpgateサーバー以外からは各店舗のサーバーに直接接続できなくなります。


薬局ならではのセキュリティ要件

要配慮個人情報の保護

薬局が扱う患者データは個人情報保護法における「要配慮個人情報」に該当します。病歴・処方内容・調剤記録など、漏洩した場合の影響は甚大です。Warpgateによるアクセス制御と監査ログは、これらの情報を保護するための技術的安全管理措置として有効です。

厚生労働省ガイドラインへの対応

「医療情報システムの安全管理に関するガイドライン」では、以下が求められています。

  • アクセス権限の適切な設定と管理
  • アクセスログの記録と保存
  • 不正アクセスの防止措置

Warpgateの RBAC、セッション録画、2FA はこれらの要件に直接対応します。

監査への備え

薬局は保健所や厚生局の監査を受ける場合があります。「どの担当者が、いつ、どのシステムにアクセスしたか」を即座に提示できる体制は、監査対応の観点からも重要です。Warpgateの Web UIからセッション一覧を検索・再生できるため、技術に詳しくない管理者でも証跡を確認できます。


導入ステップ

実際の導入は、以下のステップで段階的に進めることを推奨します。

  1. 本部サーバーにWarpgateを構築 — Docker Composeで起動し、管理者アカウントを設定
  2. Tailscaleで本部と1店舗を接続 — まず1店舗で動作確認
  3. ターゲットとロールを定義 — RBAC設計をWeb UIで設定
  4. 2FAを有効化 — 全ユーザーにTOTPを設定
  5. 残りの店舗を順次追加 — 動作確認済みの構成をテンプレートとして展開
  6. ベンダーアカウントを整備 — 必要なロールのみを付与
  7. ログ保存とバックアップを設定 — 長期保存の仕組みを構築

まとめ

薬局チェーンのITインフラ管理において、Warpgateは以下の課題を一挙に解決します。

  • SSH鍵のバラバラ管理 → Warpgateで一元的にアクセス制御
  • 退職者のアクセス削除漏れ → アカウント無効化で即座に全店舗遮断
  • ベンダーの一時アクセス管理 → ロールベースで最小権限を付与、セッション録画で作業を記録
  • 患者データの保護 → 2FA必須化、監査ログ、ネットワーク分離

オープンソースであるためライセンスコストがかからず、Docker Composeで手軽にデプロイできる点も、IT予算が限られがちな中小薬局チェーンにとって大きなメリットです。

まずは1店舗から試験導入し、効果を実感したうえで全店舗に展開していくアプローチをおすすめします。患者データを預かる薬局だからこそ、アクセス管理の強化は早期に取り組むべきテーマです。


関連記事