クラウドネイティブを学ぼう！

シークレット管理とは？

SHARE:

ITインフラストラクチャを構成するすべてのエンティティには固有の識別情報があります。ユーザーとデバイス／マシンはそれぞれ独自の識別情報を持ちます。シークレット管理は、ユーザーとデバイス／マシンの識別情報を認証し、権限付与前にそれらを検証し、識別情報を秘密に保つのに役立ちます。シークレット管理は、組織がITインフラストラクチャを保護するのに貢献します。

シークレットとシークレット管理

シークレット管理についてご説明する前に、まずシークレットとは何かをご説明いたします。パスワードは秘密にすべきものであることは、多くの方がご存知かと思います。しかしながら、シークレットと機密データの違いについてご理解いただく必要がございます。機密データには、氏名、生年月日、社会保障番号、給与などの個人情報が含まれます。一方、シークレットとは、特定のリソース、システム、および／またはデータへのアクセスを許可するデジタル認証資格情報のことです。シークレットの例を以下に示します：

  • データベース接続文字列
  • システム間パスワード
  • APIキー
  • SSHキー
  • 暗号化キー
  • X.509証明書

上記のシークレットは、ユーザーとデバイス／マシン間の通信を開始します。ユーザーからマシンへの通信、およびマシン間通信では、これらのシークレットを使用して信頼できるエンティティであることを保証します。

シークレット管理とは、組織がデジタル認証資格情報または上記のシークレットを安全に保管、取得、管理するために使用する、一元化されたツール、方法、ワークフローの集合を指します。

シークレット管理が重要な理由

シークレット管理をご利用いただく主な利点を以下に記載します：

  • セキュリティ。データが暗号化されるだけでなく、データストレージ自体も暗号化されます。このデータ暗号化は一方向暗号化です。シークレットが漏洩、侵害、または破棄された場合、それを復元する唯一の方法は新しいシークレットを作成することです。
  • 監査。組織では、シークレットの漏洩により、システムが外部または内部に晒されたり侵害されたりする可能性があります。監査ログは、こうした漏洩を特定・把握し、将来の同様の漏洩を防止するために不可欠です。
  • 一元管理。前述の通り、シークレットが組織内に散在するとシークレットスプロールが発生します。シークレットを一元管理することで、漏洩や侵害が発生した際に迅速な対応が可能となります。さらに、シークレットの一元管理により、組織はチームに依存せずにシークレットを特定できるようになります。
  • リース、失効、ローテーション。これはシークレット管理における最も重要な機能の一つです。一部のセキュリティコンプライアンス要件では、シークレットを特定の期間内にローテーションすることが規定されています。シークレット管理ソリューションは、侵害または漏洩したシークレットをすべて取り消すことを可能にします（監査ログと集中管理機能を活用）。さらに、シークレット管理は、従業員が退職した際のパスワード取り消しを支援します。
  • ポリシー。すべての従業員がすべてのリソースにアクセスできる状態は望ましくありません。例えば、ジュニア開発者は本番データベースへの書き込みアクセスではなく、読み取り専用アクセスを必要とする場合があります。システム管理者はデータベースシステムへのアクセスを必要としないかもしれませんが、SRE（サイト信頼性エンジニア）はそれを必要とします。このように、ポリシーを活用して適切なアクセス権を付与することが可能です。各従業員やチームメンバーの特定の要件に基づいてポリシーを定義する機能は、組織がシステムの安全性を維持するのに役立ちます。
  • アクセスレベル。シークレット管理により、組織はリソースへの完全なアクセスまたは制限付きアクセスを付与でき、最小権限の原則に従うことが可能となります。

シークレットの種類

定義上、シークレットはユーザーが他のリソース、システム、および／またはデータへのアクセス権を取得することを可能にします。ここでは、存在する様々な種類のシークレットについて見ていきましょう。

認証シークレット

NIST（米国国立標準技術研究所）によれば、「認証シークレット」とは、攻撃者が認証プロトコルにおいて加入者をなりすますために使用可能なあらゆるシークレット値の総称です。

この種のシークレットは、通信を開始するエンティティの身元を認証または検証するために用いられます。全てのチェックが通過または認証されると、要求に基づいて発信者は特定のリソース、システム、データへのアクセス権限を付与されます。

暗号化シークレット

認証シークレットと同様に、暗号化シークレットの主な目的は、ユーザー、デバイス／マシン、またはシステムを認証することです。暗号化シークレットにより、組織はシークレットを暗号化キーで暗号化することが可能となります。組織が利用できる暗号化方式には、いくつかの種類がございます：

  • 対称暗号化（秘密鍵暗号化）は、シークレットの暗号化と復号化に同一の鍵を使用します。
  • 非対称暗号化（公開鍵暗号化）は、2つの鍵を用いた暗号化方式です。この方法では公開鍵と秘密鍵が使用されます。認証局（CA）によって署名されたデジタル証明書により公開鍵を配布できます。秘密鍵は個人所有者のみが知るべきものです。
  • ハッシュ化は、元に戻せない一方向のデータ／シークレット暗号化です。パスワードやシークレットを忘れた場合（「パスワードを忘れた」機能やヒントを受け取る仕組みがない場合）、シークレットを「更新」する唯一の方法は、新しいシークレットを作成することです。

アプリケーションシークレット

アプリケーションシークレットは、多くのIT担当者や開発者にとって最も身近なタイプのシークレットです。その名称が示す通り、これらのシークレットはユーザーやシステムを認証し、他のシステムへのアクセスを可能にします。

多くの開発者は、DevSecOpsにこれらのシークレットの管理を任せることで開発プロセスが遅くなる可能性があると考えており、そのため開発コードの一部として保存する傾向があります。具体的には、アプリケーションロジックにハードコーディングするか、設定ファイル（config.php、config.xml、config.jsonなど）に保存する方法です。このような方法でシークレットを保存することは、アプリケーションやシステムの侵害や漏洩につながる可能性のある悪い慣行です。

シークレット管理ソリューション

ここまでで、シークレット管理の重要性と、悪意のある者の手に渡った場合にシステム侵害や漏洩につながる可能性のある様々な種類のシークレットについてご理解いただけたかと思います。シークレット管理が組織のIT運用マニュアルに組み込まれるべきであることは明らかです。

シークレット管理ソリューションの仕組み

前のセクションで、アプリケーション内にシークレットを保存したりハードコーディングしたりすることは避けるべき手法であることがお分かりいただけたかと思います。例えばGitなどのバージョン管理ツールにシークレットを保存することにも十分ご注意ください。ハッカーはGitHubリポジトリをスキャンし、意図的・非意図的にコミットされたシークレットや類似情報を発見することが可能です。そしてそれらのシークレットを悪用する可能性があります。

シークレット管理はこれらの課題を解決します。シークレット管理ソリューションは、すべてのシークレットを中央集約型の安全な場所に保管し、ポリシーやアクセスレベルの適用を可能にします。また、システムが侵害された場合やコンプライアンス要件（例：60日ごとのパスワード更新義務）を満たすために、シークレットの貸与、失効、ローテーションを組織が実施する機能も提供します。

シークレット管理ツールの導入は開発者にとっても非常に有益です。シークレットの取得・保存場所が常に明確になるためです。開発者はローカル環境での作業、CI/CDプロセス、ソフトウェア開発ライフサイクルの全段階においてシークレット管理ツールを活用できます。

キー管理システム

データやシークレットを保護するためには、暗号化（転送中または保存時）を使用することがベストプラクティスです。キー管理システムでは、データやシークレットの暗号化および復号化を行うための暗号鍵を作成します。これらの暗号鍵にはポリシーを紐付けることができ、これによりデータへのアクセス権限やアクセス方法、タイミングを規定することが可能です。

一部のキー管理システムでは、キー管理操作、ライフサイクルイベント、使用状況の識別機能を提供しています。これらの機能は、組織がセキュリティポスチャーを強化し、コンプライアンス要件の一環としてシステムを監査するのに役立ちます。

シークレット管理プラットフォーム

クラウドおよびオンプレミスインフラストラクチャ、Kubernetes、コンテナはいずれもシークレットとの連携が必要です。市場には複数のシークレット管理プラットフォームやツールが存在します。以下にいくつかご紹介します。

HashiCorp Vaultは、集中管理型のIDベースのシークレットおよび暗号化管理システムです。保存時（Vault内部）および転送中のデータを暗号化し、組織のニーズに基づいてアクセスポリシーを作成できるACL機能も提供します。Vaultの監査証跡により、組織はシークレットの使用状況、アクセス方法、ローテーション状況などについて、より詳細な可視性を得ることができます。

Vaultの主な利用例には以下が含まれます：

  • シークレット管理
  • 動的シークレット
  • Kubernetesシークレット
  • データベース認証情報のローテーション
  • 自動化されたPKIインフラストラクチャ
  • IDベースのアクセス制御
  • データ暗号化とトークン化
  • キー管理

例えばウェブアプリケーションでは、開発者が例外処理を実装する方法（ユーザー名とパスワードをスローする）、APIキーをキャプチャするロギングシステム、接続文字列や暗号化キーを表示するアプリケーション監視パフォーマンスシステムなどにより、シークレットが漏洩する可能性があります。これを完全に防止することはできませんが、an use HashiCorp Vault’s dynamic Secrets to create short-lived and temporary credentials to mitigate the problem.

TVaultを理解し習得するためのドキュメントやチュートリアルが多数用意されております。Vaultについて知っておくべき最も重要な点の一つは、ポリシーに関連付けられたトークンを使用する点です。組織のニーズに基づいてポリシーを定義することが可能です。こうしたポリシーは、読み取り、書き込み、作成、更新、削除、またはそれらの組み合わせに対して設定できます。Vaultでは、必要に応じてトークンの失効、更新、ローテーションを行う機能も提供しております。

HashiCorp Vaultはクラウドベースのインフラストラクチャと非クラウド環境の両方でご利用いただけます。クラウドプロバイダーに依存せず、多数のサードパーティ製統合機能をサポートしております。

クラウドベースのシークレット管理サービス

HashiCorp Vaultは特定のクラウドベンダーに依存しませんが、AWS Secrets ManagerやAmazon Simple Systems Manager（SSM）など、複数のクラウドベースのシークレット管理サービスが利用可能です。

AWS Secrets Managerは、アプリケーションやシステムがAPI呼び出しを通じてシークレットの作成、削除、ローテーション、暗号化、復号化、利用を可能にする、AWSの集中管理型シークレット管理システムです。コード内にパスワードをハードコーディングする代わりに、AWS Secrets ManagerへのAPI呼び出しにより、認証情報、APIトークン、その他のシークレットを取得します。

AWS Secrets Managerは以下の機能を提供します：

  • 実行時のシークレット/パスワード取得。必要な際に、AWS Secrets Managerから保存された認証情報を動的に取得できます。
  • 様々なタイプのシークレットの保存。AWS Secrets Managerでは、暗号化されたシークレットやデータベース接続文字列を保存できます。
  • シークレットデータの暗号化。AWS Secrets Managerは、AWS Key Management Service (KMS)を使用してシークレットデータを暗号化します。
  • シークレットの自動ローテーション。コンプライアンス要件によっては、パスワードやシークレットのローテーションが義務付けられる場合があります。AWS Secrets Managerでは、ユーザー介入なしにシークレットのローテーションを設定・スケジュールできます。AWS Lambda関数でローテーションを定義します。
  • データベースシークレットのローテーション。AWS Secrets Managerは、Amazon Aurora、MySQL、PostgreSQL、Oracle、MariaDB、Microsoft SQL ServerなどのAmazon Relational Database Service (RDS) データベース向けシークレットローテーションをサポートします（これらはAmazon RDSで設定されます）。
  • その他の AWS サービスにおけるシークレットのローテーションをサポート。例えば、AWS Secrets Manager は Amazon DocumentDB や Amazon Redshift におけるシークレットのローテーションをサポートしております。
  • アクセス制御。IAM ポリシーをアタッチすることで、誰（ユーザー、グループ、ロール）が何を（シークレット）にアクセスできるかを細かく制御できます。例えば、特定のグループにはフルマネージドポリシーをアタッチし、他のグループには読み取り専用ポリシーを適用することが可能です。
  • コンプライアンス。AWS Secrets Manager は、HIPAA、ISO、ペイメントカード業界データセキュリティ基準（PCI DSS）、システムおよび組織統制（SOC）、連邦リスク認可管理プログラム（FedRAMP）、国防総省（DOD）クラウドコンピューティングセキュリティ要件ガイド（SRG）、情報セキュリティ登録評価者プログラム（IRAP）、および外部サービスプロバイダー監査報告書 (OSPAR)などのコンプライアンス基準に準拠しております。

AWS Systems Manager（旧称 Amazon Simple Systems Manager — SSM — および Amazon EC2 Systems Manager）はエージェントベースのアプリケーションです。つまり、システムに SSM エージェントをインストールする必要があります。コマンドを発行する際、SSM エージェントはクライアントとして動作し、SSM サーバーへの接続を開始し、SSM サーバーが受信したコマンドを処理します。SSMサーバーがコマンドを完了すると、結果をSSMエージェントに返します。SSMエージェントは結果をクライアントアプリケーションまたはシステムに渡します。

SSMでは、Amazon EC2インスタンス、エッジデバイス、オンプレミスサーバー、仮想マシンなどのリソースを更新、管理、構成できます。これらのエンティティ間の通信はSSMエージェントを介して行われます。IAMポリシーを使用してSSMを通じて実施可能な例としては、ルートレベルアクセスコマンドの制限、IAMポリシーでタグを指定してユーザーがコマンドを実行する権限を制限すること、タグに基づくアクセス制限などが挙げられます。

AWS Secrets ManagerとAWS Systems Manager（SSM）には、いくつかの重要な相違点がございます。SSMはキーローテーションやポリシーの添付をサポートしておらず、また4KBのサイズ制限があります（一方、AWS Secrets Managerは10KBの制限です）。したがって、どちらを使用するか選択する前に、アプリケーションの要件（例えば、シークレットのローテーションが必要かどうか、シークレットのサイズがどれくらいになるか、その他のコンプライアンス要件を満たす必要があるかどうかなど）を必ずご確認ください。

Kubernetesにおけるシークレット管理では、シークレットと呼ばれるオブジェクトが、トークン、SSHキー、証明書、認証情報など、シークレットと見なされるものを保存するために使用されます。シークレットの乱立を防ぐため、KubernetesシークレットはPodのライフサイクルを定義するアプリケーションコードから分離されています。そのため、Podが作成・削除されてもシークレットはそのまま維持されます。新しく作成されたPodは、シークレット（データ）をボリュームとしてマウントするだけです。Kubernetes Secrets の特徴は以下の通りです：

  • Kubernetes Secrets は base64 エンコードされます。
  • データボリュームとしてマウント可能です。
  • 環境変数として定義することも可能です。
  • ネームスペースが割り当てられます。
  • サイズ制限は 1MiB です。

Kubernetes Secrets を適切に保護するには、ロールベースのアクセス制御（RBAC）を活用する必要があります。RBACを使用すると、ユーザーロールに基づいてKubernetes Secretsへのアクセスを制御できます。また、ClusterRolesを使用して、クラスタおよびネームスペース内でユーザーが実行できる操作（動詞）を定義することも可能です。

以下のKubernetes公式サイトの例は、ClusterRoleを使用して、任意のネームスペース内または全ネームスペースにわたる（バインド方法に依存）Secretsへの読み取りアクセス権を付与する方法を示しています：

apiVersion: rbac.authorization.k8s.io/v1
kind: ClusterRole
metadata:
  # "namespace" omitted since ClusterRoles are not namespaced
  name: secret-reader
rules:
- apiGroups: [""]
  #
  # at the HTTP level, the name of the resource for accessing Secret
  # objects is "secrets"
  resources: ["secrets"]
  verbs: ["get", "watch", "list"]

シークレット管理のベストプラクティス

効果的なシークレット管理は、ベストプラクティスに従うことに尽きます。シークレット管理の導入を計画する際には、組織のニーズ、セキュリティ要件、選択するソリューションの使いやすさなどを考慮する必要があります。最も重要な4つのポイントに絞ってご説明いたします：

  • 安全な保管と配布。シークレット管理ソリューションを選択する際には、各ソリューションが提供する優れた機能全般に焦点を当て、データやシークレットの保管方法と伝送方法を確認すべきです。保存時および転送中のデータとシークレットを暗号化してください。
  • アクセス制御とガバナンス。アクセス制御とポリシーはITインフラの不可欠な要素となり、最も重要な部分であると言えるでしょう。これらは、組織が誰が何をアクセスできるかを制限する能力を提供します。シークレット、データ、インフラストラクチャを保護するために必要なあらゆるポリシー（読み取り専用、読み書き、管理者アクセス権の付与など）を作成できます。
  • シークレットの定期的なローテーションと有効期限管理。チームメンバーが組織を離れる場合、その個人が保持するAPIキーやその他の重要な認証情報が、チーム内の他の誰も知らない状態になる可能性があります。シークレットのローテーションは、このようなシナリオだけでなく、システム侵害の可能性を防ぐためにも不可欠です。
  • コンプライアンスのための監査と監視。監査と監視により、組織はどのシークレットが、どのように、誰によってアクセスされたかを把握できます。この情報をもとに、アクセス制御やポリシーの追加・変更を行い、セキュリティポスチャーを強化することが可能です。さらに、多くの組織ではコンプライアンス要件を満たすために監査と監視の実施が必須となります。

結論

シークレット管理は、組織がシステムとインフラストラクチャを保護するのに役立ちます。ユーザーからマシンへの通信、およびマシン間通信には、身元確認が必要です。ユーザーやマシンの身元確認には、パスワード、APIキー、暗号化キー、証明書などが使用され、これらはシークレットと呼ばれます。シークレット管理の導入は、始めると気が遠くなるような作業に思えるかもしれません。もしシークレット管理が組織の次の優先事項であるならば、より大きな効果を得るために、まずは小規模から始めることをお勧めします。まずは上記でご説明したツールを用いてシークレットの保護から始めましょう。次に、保存時および転送時のデータ暗号化の採用と、ポリシーに基づくアクセス制御の導入によりシークレット管理を強化します。その後、定期的なシークレットのローテーションを次の課題として取り組むべきです。さらに、シークレットの動作を監査・監視し、組織のインフラセキュリティポスチャーを分析する基盤を構築することが重要です。