VaultのProduction環境での運用を検討している中で、HashiCorp社の公式Docの中のProduction Hardeningを読んだので、内容をまとめておくことにする。

producion環境で強固な運用をおこなう

本ガイドは、本番環境でVaultのdeploymentを強固に行う為のベストプラクティスを記すガイダンスである。 これらのrecommendationsはSecurity Modelに基づく。

このガイドはVaultの理想的なdeploymentのガイダンスを提供することを目的としている。 現在のガイドでは、recommendationsは次の2つに分かれている。

• Baseline recommendations: 本番環境では可能な限り全て適用するべきもの
• Extended recommendations: 追加のセキュリティ層で、運用負荷が増えることがあり、全ての環境に向くとは限らないもの

本記事の項目のうち、Disable SSH / Remote Desktop、Immutable Upgrades、Configure SELinux / AppArmor、Tweak ulimits、Docker ContainersはExtendedに分類されている。

Recommendations

End-to-End TLS.

• Production環境では、Vaultは常にTLSを利用するべき。
• もしVaultの前段にロードバランサ/リバースプロキシがいる場合は、外部ストレージを含め、システムの全ての区間の通信でTLSを有効にするべきである。
• Vaultへのトラフィックを常時暗号化することで、中間レイヤでのリスクを最小化することが出来る。
• 可能であれば、Vaultのcustom response headers機能でHSTSヘッダを設定する。

Single Tenancy.

• Vaultはマシン上で実行する唯一のメインプロセスであるべき。
• 同じマシン上で動く他のプロセスが危険にさらされ、Vaultとやり取りするリスクを減らすため。
• 同様に、VMよりもベアメタル、コンテナよりもVMで動かすことが望ましい。

Firewall traffic.

• local firewallやクラウドプロバイダのネットワークセキュリティ機能を使って、VaultとNTPのような必要不可欠なサービスへのincoming/outgoingトラフィックを制限しよう。
• incomingのトラフィックは許可されたサブネットからのみにして、outboundのトラフィックは（Databaseのような）Vaultを利用する上で必要不可欠なサービスに絞るべきである。

Disable SSH / Remote Desktop

• シングルテナントのアプリケーションとしてVaultを動作させる時、ユーザは決して直接マシンにアクセスしてはいけない。
• 代わりに、ネットワーク経由のAPIを通してアクセスするべきである。
• デバッグには集中管理されたログ・テレメトリの仕組みを使い、ログへのアクセスは必要な人だけに制限しよう。

Disable Swap

• Vaultは転送及び保存中のデータを暗号化する。機能する為には、sensitiveなデータがメモリ上に存在する必要がある。
• OSがデータをディスクにページすることを防ぐ為にswapを無効化することで、漏洩リスクは最小化すべき。
• Integrated Storageを使う場合は、swapの無効化がさらに重要になる。（Integrated Storageではmlockの無効化が強く推奨されており、mlockでswapを防げないため）

Don't Run as Root.

• Vaultは非特権ユーザで稼働するように設計されている。Vault encryption keyにアクセス出来て、Vaulr process memoryをexpose出来る、root/Administratorで動かす必要はない。
• 通常のユーザとしてVaultを動かすことは、その権限を減らすことになる。VaultのConfigulationで、Vault Userのみにアクセスを制限する為の権限設定をおこなう必要がある。

Turn Off Core Dumps.

• core dumpを強制実行し結果ファイルにアクセス可能なユーザ（Administrator）は、潜在的にVaultのencryption keyにアクセス可能である。

Immutable Upgrades.

• Vaultはデータ永続化の為に外部ストレージに依存する。
• この分離により、Vaultが稼働するServerを不変（Immutable）に管理することが出来る。
• 新しいバージョンにアップグレードする際には、まず新しいバージョンのVaultが稼働するサーバをオンラインで起動する。
• それらは同じストレージバックエンドにアタッチされ、（手動あるいは自動で）unsealedされる。
• その後、古いサーバを削除する。
• これにより、Security Gapをもたらす可能性のある、リモートアクセスやアップグレードオーケストレーションの可能性を減らせる。

Avoid Root Tokens.

• Vaultは、最初の初期化の際に、RootTokenを用意する。
• このTokenはシステムの初期セットアップ、特にユーザが認証できるようにする為のAuthMethodsのセットアップにに使用されるべきである。
• Vaultの設定はコード化すること、version controlを使ってポリシーを管理することを勧める。
• 一度セットアップされたら、RootTokenは漏えいリスクを取り除く為に廃棄されるべきである。
• RootTokenは必要になれば生成出来るので、できるだけ早く無効化するべきである。

Enable Auditing.

• Vaultはいくつかのaudit devicesをサポートしている。
• 監査を有効にすることで、Vaultによって実行された全ての操作履歴が表示され、悪用や漏洩が発生した場合のforensict trailが提供される。
• Audit logsは機密データをセキュアにハッシュ化する
• しかし、意図しない開示を防ぐ為に、アクセスは制限されるべきである。

Upgrade Frequently.

• Vaultは積極的に開発されており、セキュリティ修正やkey lengthやcipher suitesなどのデフォルト設定におけるあらゆる設定を取り込む為に、頻繁なアップデートは重要である。
• HashiCorp Announcement mailing listを購読し、各リリースの変更点はVault CHANGELOGで確認しよう。

Configure SELinux / AppArmor

• SELinuxやAppArmorのような追加機構を用いることで、Vaultを使用する際に、別レイヤーでのセキュリティを与えることができる
• Vaultは多くのOSで動作するが、セキュリティの為にLinuxで動かすことを推奨する

Restrict Storage Access.

• Vaultは、どんなStorage Backendを使っていたとしても、保存時に全てのデータを暗号化する。
• データは暗号化されるが、任意の権限を持った攻撃者によって、データの破損や損失、キーの変更や削除を引き起こされる可能性がある。
• Storage Backendへのアクセスは、認証されていないアクセスを防ぐ為に、Vaultからのアクセスにのみ制限するべきである。

Disable Shell Command History.

• Vaultコマンドがシェルのhistoryに残らないようにしよう（こちらの「How do I enter my secrets without exposing the secret in my shell's history?」を参照）

Tweak ulimits

• 多くのLinuxディストリビューションはulimitsを制御することが可能である。
• 最大オープンファイル数、接続数の制限を確認すること。増やす必要があるかもしれない。

Docker Containers

• Vaultコンテナ内部のmemory lock機能を有効化する為には、overlayfs2や他のドライバーサポートを使用する必要があるかもしれない。

現在のガイドで追加された主な項目

2019年以降、ガイドには次のような項目が追加されている。詳細はProduction Hardeningを参照。

• Baseline recommendations
  • Allow minimal write privileges: Vaultのサービスアカウントには、Vaultのバイナリや設定ファイルへの書き込み権限を与えない
  • Configure user lockout: approle・ldap・userpassのuser lockout（デフォルトで有効）の閾値と期間を確認する
  • Log file management: ログのローテーション・圧縮や、集中管理先への転送を検討する
  • Synchronize clocks: NTPなどで全ノードの時刻を揃える
  • Do not use clear text credentials: sealスタンザにクラウドの認証情報やHSMのPINを平文で書かない
  • Use the safest algorithms available: 可能であればTLS 1.3を使う
  • Use standard input for vault secrets: vault loginやvault operator unsealでは、シークレットをコマンドライン引数ではなく標準入力から渡す
  • その他、プラグインのベストプラクティス、設定ファイルのマージ、ファイルパーミッション、オフボーディング手順、短いTTL、最小権限のシンプルなポリシーに関する項目がある
• Extended recommendations
  • Use systemd security features: ProtectSystemやNoNewPrivilegesなどsystemdの機能で権限を絞る（公式Linuxパッケージのunitファイルでは一部がデフォルトで設定済み）
  • Consider memory usage when configuring disable_mlock with integrated storage: mlockを無効にする場合は、swapファイルを暗号化する
  • Consider using a separate partition for integrated storage: Vaultがストレージを使い切っても影響を抑えられるよう、専用パーティションを使う
  • その他、管理用namespaceの利用、認証付きリバースプロキシ、outbound proxy、deny_slash_in_templated_pathsの設定に関する項目がある