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

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

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

このガイドはVaultの理想的なdeploymentのガイダンスを提供することを目的としている。 以下のrecommendationsすべての適用しなくても、Vaultを使うことはできるが、可能な限り適用したほうがいい。

Recommendations

End-to-End TLS.

  • Production環境では、Vaultは常にTLSを利用するべき。
  • もしVaultの前段にロードバランサ/リバースプロキシがいる場合は、そこでTLSを終端させるべきではない
  • Vaultへのトラフィックを常時暗号化することで、中間レイヤでのリスクを最小化することが出来る。

Single Tenancy.

  • Vaultはマシン上で実行する唯一のメインプロセスであるべき。
  • 同じマシン上で動く他のプロセスが危険にさらされ、Vaultとやり取りするリスクを減らすため。
  • VMやコンテナでのデプロイメントもワークはするけど、リスクを最小限に抑える為には、避けるべきである。

Firewall traffic.

  • Vaultはwell knownポートでlistenし、あらゆるincoming/outgoingトラフィックやNTPのような必要不可欠なサービスを制御する為に、local firewallを使おう。
  • incomingのトラフィックは許可されたサブネットからのみにして、outboundのトラフィックは(Databaseのような)Vaultを利用する上で必要不可欠なサービスに絞るべきである。

Disable SSH / Remote Desktop

  • シングルテナントのアプリケーションとしてVaultを動作させる時、ユーザは決して直接マシンにアクセスしてはいけない。
  • 代わりに、ネットワーク経由のAPIを通してアクセスするべきである。
  • 必要に応じて、ログへのアクセス制御を実施するようにしよう。

Disable Swap

  • Vaultは転送及び保存中のデータを暗号化する。機能する為には、sensitiveなデータがメモリ上に存在する必要がある。
  • OSがデータをディスクにページすることを防ぐ為にswapを無効化することで、漏洩リスクは最小化すべき。
  • Vaultは自動的に物理メモリへの"memory lock"を試みるが、swapを無効化すると、別のlayer of defenseが追加される。(ココらへんはよくわかってない。。)

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

Upgrade Frequently.

  • Vaultは積極的に開発されており、セキュリティ修正やkey lengthやcipher suitesなどのデフォルト設定におけるあらゆる設定を取り込む為に、頻繁なアップデートは重要である。
  • Vault mailing listやGitHub 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に残らないようにしよう(こちらを参照)

Tweak ulimits

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

Docker Containers

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