メインコンテンツまでスキップ

🔐 セキュリティ

はじめに​

Semaphore UI ではセキュリティを最優先事項としています。重要なインフラ作業を自動化する場合でも、機密システムへのチームのアクセスを管理する場合でも、Semaphore UI は堅牢で安全な運用を標準で提供できるように設計されています。このセクションでは、Semaphore がセキュリティをどのように扱っているか、また本番環境に導入する際に検討すべき点を説明します。

認証と認可​

Semaphore は、安全な認証と柔軟な認可のしくみに対応しています。

  • ログイン方法:

    • ユーザー名／パスワード
      Semaphore のデータベースに保存された認証情報を使用する既定の方法です。パスワードが平文で保存されることはなく、Argon2id でハッシュ化されます（パスワードのハッシュ化を参照）。

    • LDAP
      企業のディレクトリサービスと連携できます。ユーザー／グループのフィルタリングと、LDAPS による安全な接続に対応しています。

    • OpenID Connect (OIDC)
      Google、Azure AD、Keycloak などの ID プロバイダーによるシングルサインオンを利用できます。カスタムクレームとグループマッピングに対応しています。

  • 2 要素認証 (2FA)
    TOTP ベースの 2FA を利用でき、すべてのユーザーに推奨されます。ユーザーごとに有効化でき、任意でリカバリーコードを使用できます。設定オプション mfa.totp.enabled と mfa.totp.allow_recovery を参照してください。

  • ロールベースのアクセス制御
    ユーザーに管理者、メンテナー、閲覧者などの異なるロールを割り当て、責任範囲に応じてアクセスを制限できます。

  • セッション管理
    セッションはセキュアな HTTP クッキーで保護されます。セッションの有効期限とログアウトのしくみにより、露出を最小限に抑えます。

パスワードのハッシュ化​

v2.20 以降

Argon2id によるパスワードのハッシュ化は Semaphore 2.20 以降で利用できます。それより前のバージョンでは bcrypt を使用します。

ローカルユーザーのパスワードは、OWASP がパスワード保存に推奨しているアルゴリズムである Argon2id でハッシュ化されます。Semaphore は OWASP の最低強度パラメーターを使用します。

パラメーター値
メモリ19 MiB (m=19456)
反復回数2 (t=2)
並列度1 (p=1)
ソルトパスワードごとにランダムな 16 バイト
ハッシュ長32 バイト

ハッシュは標準の PHC 文字列形式（例: $argon2id$v=19$m=19456,t=2,p=1$<salt>$<hash>）で保存されるため、各ハッシュに使用されたパラメーターもあわせて記録されます。

これは、パスワードを設定するあらゆる方法に適用されます。Web UI、API、および CLI コマンド semaphore user add、semaphore user change-by-login、semaphore setup のいずれでも同様です。

2.20 より前のバージョンからのアップグレード。 2.20 より前のリリースでは、パスワードを bcrypt でハッシュ化していました。移行作業は必要ありません。

  • 既存の bcrypt ハッシュはログイン時にそのまま受け付けられるため、アップグレード後もすべてのユーザーが引き続き利用できます。
  • 最初のログインが成功した時点で、パスワードは自動的に Argon2id で再ハッシュ化され、bcrypt のハッシュが置き換えられます。
  • 将来のリリースで Semaphore の Argon2id パラメーターが強化された場合も、古いパラメーターで作成されたハッシュは次回のログイン時に同じ方法でアップグレードされます。

再ハッシュ化はログイン時にのみ行われるため、その後一度もログインしないユーザーは bcrypt のハッシュを保持したままになります。そのようなアカウントを強制的にアップグレードするには、semaphore user change-by-login --password ... または管理 UI からパスワードをリセットしてください。

注記

2 要素認証のリカバリーコードはユーザーのパスワードではないため、引き続き bcrypt を使用します。

シークレットと認証情報​

シークレットを安全に管理することは中核的な機能です。

  • 暗号化されたキーストア
    認証情報とシークレット変数は、AES 暗号化により保存時に暗号化されます。

  • 環境の分離
    シークレットは実行時にのみジョブへ渡され、コンテナー環境に直接公開されることはありません。

  • SSH キーとトークン
    有効な SSH キーとトークンをアップロードする責任はユーザーにあります。これらは暗号化され、タスクの実行時にのみ使用されます。

  • HashiCorp Vault 連携 (Pro)
    シークレットを外部の Vault インスタンスに保存できます。シークレットの作成時または編集時に、保存先をシークレットごとに選択します。

データの暗号化​

機密データは暗号化された形式でデータベースに保存されます。アクセスキーの暗号化を有効にするには、設定ファイルで設定オプション access_key_encryption を指定してください。この値は次のコマンドで生成する必要があります。

head -c32 /dev/urandom | base64

信頼できないコードや playbook の実行​

Semaphore はユーザーが定義した playbook やコマンドを実行するため、リスクが伴う可能性があります。

  • 実行の分離
    既定では、タスクは Semaphore サーバー上の通常のプロセスであり、そのサーバーのファイルシステムとネットワークにアクセスできます。分離は任意です。docker または k8s エグゼキューターを設定した ランナー にタスクを渡すと、タスクごとに新しいコンテナーまたは Pod が作成され、終了時に破棄されます。

  • 最小権限
    Docker および Kubernetes エグゼキューターでは、イメージ、ネットワーク、サービスアカウントを自分で選べるため、タスクには必要なものだけを与えられます。

  • chroot による実行
    Semaphore は chroot jail 内でタスクを実行し、実行環境をホストシステムからさらに分離できます。

  • タスクプロセスのユーザー
    タスクは専用の非 root システムユーザー（例: semaphore）として実行でき、潜在的な脆弱性悪用の影響を軽減できます。これは任意であり、システムのポリシーに応じて設定できます。

安全なデプロイ​

Semaphore を安全にデプロイするには、次の点に注意してください。

  • HTTPS を使用する
    Semaphore は、組み込みの TLS サポート と Nginx などのリバースプロキシ の両方で HTTPS に対応しています。本番環境では HTTPS を有効にすることを強く推奨します。

    組み込みの HTTPS サポートを有効にするには、config.json に次のブロックを追加します。

    {
        ...
        "tls": {
            "enabled": true,
            "cert_file": "/path/to/cert/example.com.cert",
            "key_file": "/path/to/key/example.com.key"
        }
        ...
    }

  • ファイアウォールの背後で実行する
    Semaphore UI とデータベースへのアクセスを、信頼できる IP アドレスのみに制限します。

  • データベースのセキュリティ
    強力なパスワードを使用し、データベースへのアクセスを Semaphore のみに制限します。

更新とパッチ管理​

セキュリティ更新は定期的に公開されています。

  • 最新の状態を保つ
    常に最新の安定版リリースを使用してください。

  • 変更履歴
    更新前に GitHub で変更内容を確認してください。

  • 自動更新
    Docker を使用している場合は、定期的な更新のための自動化パイプラインを検討してください。

脆弱性の報告​

脆弱性を見つけた場合は、Semaphore の安全性維持にご協力ください。

脆弱性の解決目標​

報告された脆弱性は、次の目標期間内に解決することを目指しています。

  • 緊急: 30 日以内
  • 高: 60 日以内
  • 中: 90 日以内
  • 低: ベストエフォート。通常は 180 日以内

最新の安定版リリースに影響し、実際に悪用されている問題については、通常のサイクル外でパッチをリリースする場合があります。

コードセキュリティのツール​

コードベースと依存関係の解析、および依存関係の更新の自動化には、CodeQL、Codacy、Snyk、Renovate を使用しています。

  • 公開された攻撃コードを共有しない
    パッチが提供されるまで、脆弱性を公開しないでください。

  • 謝辞
    ご希望に応じて、セキュリティ研究者の方をリリースノートで謝辞として記載することがあります。