アプリケーション セキュリティにおけるシークレットとは、認証・認可プロセスで所有者が主張している本人および本物であることを証明する情報です。攻撃者がシークレットにアクセスできると、システムに不正にアクセスして、企業秘密や顧客情報を盗んだり、データと引き換えに金銭を要求したりするなど、さまざまな目的に使用する可能性があります。
代表的な例は、データベースへのアプリケーション アクセスを許可するユーザー名とパスワードですが、他にAPIキー、認証情報、証明書、秘密鍵などの情報もシークレットにあたります。シークレットは組織の資産へのアクセス制御に使用されるため、組織が侵害されるリスクを低減するには、シークレットを安全に保管して保護することが不可欠です。
シークレット管理とは、以下を行うために組織が使用するプロセスです。
組織がモノリシック アーキテクチャからマイクロサービス アーキテクチャに移行すると、独立して機能するアプリケーションやインフラストラクチャのコンポーネントが増え、それぞれに認証情報があるため、管理すべきシークレットが増えることになります。
シークレットを安全に保管するための2つの選択肢を詳しく見てみましょう。
ボールト アプローチでは、サードパーティのシークレット管理ツールをインストールする必要があります。ボールト ソリューションは、不正なユーザーがアクセスできないように各シークレットを暗号化します。ボールトは、設定されたポリシーに基づいてユーザーにシークレットへのアクセスを提供するためのAPIを公開します。APIのユーザーがそのAPIで認証されると、そのユーザーは認可されたシークレットにのみアクセスできます。
デメリット：
メリット：
開発者が暗号化されたシークレットを保管して管理するために使用できるツールは、多数市販されています。一元管理の自動シークレット管理ツールの使用方法の例については、当社のブログ「NGINXでHashiCorp Vaultを使用したSSL秘密鍵の保護」をお読みください。
もう1つのアプローチは、クラウド プロバイダをSecrets Management as a Serviceとして使用することです。1つのメリットとして、シークレット管理ツールが通常、マネージド データベースなどの他のクラウド サービスと緊密に統合されていることが挙げられます。また、クラウド プロバイダ サービスは、自動ローテーションなどの機能を提供している場合もあります。ただし、この機能がダウンタイムを引き起こすかどうかについては、今後の調査が必要です。
デメリット：
メリット：
シークレットのロックが解除され、アクセスされたときに、アプリケーションに混乱が生じるのを防ぐため、シークレットは慎重に管理する必要があります。ベスト プラクティスは、シークレットを決してソース管理システムに保管しないことです。ソース管理システムにシークレットを保管すると、チームや個人がコードやアプリケーションを更新するときに誤ってシークレットにアクセスしたり、シークレットが侵害されたりした場合、組織に大惨事を招く可能性があります。そのため、一時的でもシークレットがソース管理システムに保管されたら、侵害されたものとして扱う必要があります。その機密データをリポジトリから削除し、ソース管理システムの履歴からスクラブする必要があります。