こんな状況を想像してみてください アプリケーションを構築していてサービス接続用のAPIキー データベースのパスワードあるいはストレージアカウントキーが必要 になったとしますそこでコード内に直接記述したり 設定ファイルや環境変数に保存したりしますGitHubにプッシュしたりチームメイト とノートブックを共有したりするまでは全て順調に動作しますしかしその瞬間秘密の情報はもう 秘密ではなくなってしまいますもしそのコードが悪意のある手に 渡ればシステム全体が危険にさらされますそこでこの問題を解決するツール がアジュールキーファウルトですコード内に情報を残すことなく 安全に秘密を保管できる場所を提供しますしかし多くの人が誤解している ことがありますキーファウルトを使っているから といって自動的に安全になるわけではありませんどのように設定しアクセスを制御 し権限を割り当てるかが同じくらい重要ですこのエピソードの終わりにはキーファウルト の正体格納できるものアクセスの仕組みそして秘密が漏えいする 最大の過ちについて理解できるでしょう専門用語を使わず分かりやすい 言葉で必要な要点だけをお伝えしますではアジュールキーファウルトとは 一体何なのでしょうかアジュールキーファウルトとは何か最もシンプルな定義はこうですアジュールキーファウルトは秘密 情報を守るためのクラウドベースのデジタル金庫ですAPIキーデータベースのパスワード 接続文字列暗号化キー証明書を一元管理できるマイクロソフト のマネージドサービスですパッチ適用や稼働時間セキュリティ はアジュールが管理するためインフラを心配する必要はありませんただ利用するだけですオフィスビルを想像してみてくださいワークステーションや会議室キャビネット がありますが地下には重要なものを保管する頑丈な金庫室がありますマスターキー現金法的な書類など です許可と認証がなければ誰もそこには 入れませんそして誰かがドアを開けるたびに ログが記録されますそれがキーファウルトですあなたのアジュールアーキテクチャ というビルの地下にある安全な部屋なのですでは昔のやり方と比較してみましょう20年前データベースのパスワード が必要なときは設定ファイルや環境変数にハードコードするか 最悪の場合ソースコードに平文で残していました誰かがサーバーにアクセスできれば 全てが奪われていましたまたパスワードを変更する必要がある ときは至る所を更新しなければなりませんでした全ての設定ファイル全ての環境 全てのデプロイメントでですまさに悪夢でしたキーファウルトはそれを全て変え ますコードや設定ファイルに秘密を散らばせる 代わりに一つの場所に集約して保管しますアプリケーションが必要なとき にだけ実行時にそれを要求するのです全てが一元管理されているため 一箇所でシークレットをローテーションすればそれを使用する全ての アプリケーションがコード変更や再デプロイなしで自動的に新しい 値を取得できますしかし重要なのはキーファウルト は単なるアプリ向けのパスワードマネージャーではないということ ですこれは中核となるセキュリティ サービスなのですあらゆるアジュールサービスと統合 できますアップサービスファンクションズ アクスデータファクトリーシナプスロジックアップスデブオプスパイプライン など全てがキーファウルトとの連携に対応していますこれが皆さんのセキュアなクラウド アーキテクチャのバックボーンとなります一度正しく設定してしまえば認証 情報の管理について考える必要は完全になくなります何が保存できるのでしょうかキーファウルトが何であるか理解 できたところで実際に何を入れることができるのかを見ていきましょう主なカテゴリーは3つありますシークレットキーそして証明書 ですそれぞれ役割が異なりその違い を理解することがキーファウルトを正しく活用する鍵となりますまずはシークレットから始め ましょうこれは最も一般的に保存される ものですシークレットとは接続文字列 apiキー データベースのパスワードストレージアカウントキーなどアプリが他 のサービスと通信するために必要な日常的な認証情報のすべて ですこれらをコードや設定ファイル に記述する代わりにキーファウルトに保存しますアプリは実行時にこれらを取得 するため誰にもプレーンテキストで晒されることはありませんデジタルファイリングキャビネット にある鍵付きの引き出しのようなものだと考えてください次はキーですこれは保存データデータアドレスト を暗号化するための暗号化キーですazureストレージsqlデータベースあるいは 仮想マシンのディスク暗号化にカスタマー管理キーを使用する 場合それらのキーをキーファウルトに保存できますこれにより誰がいつそれを使用 できるかを完全に制御できますコンプライアンス上の理由で ハードウェアベースのキーが必要な場合もプレミアムティアの hsm 保護機能が対応します最後は証明書ですwebアプリapi内部サービス向け のtlsおよびssl証明書ですキーファウルトはそれらを保存 しライフサイクルを管理し期限が近づけば自動更新することさえ 可能です日曜日の午前3時に証明書の期限 が切れて困った経験がある人にとってはまさに救世主と言える でしょう具体的な例を挙げますデータベースの接続文字列と サードパーティサービスのapiキーを必要とするwebアプリを 創造してください従来の方法では両方をアプリ 設定のjsonファイルに記述していましたもしそのファイルがリポジトリ に残ってしまえばコードにアクセスできる全員がデータベースの認証 情報を見ることができてしまいますキーファウルトを使えば両方の 値をsecretとして保存しますアプリは起動時にこれらを取得 するためソースコード上に表示されることはありませんデータベースのパスワードを ローテーションする必要がありますかキーファウルトで更新するだけ です次の再起動時にアプリは自動的 に新しい値を取得しますコードの変更も再デプロイも不要 です意外と知られていないのがバージョン 管理機能が組み込まれている点ですsecretを更新してもキーファウルトは 古い値を上書きしません新しいバージョンを作成します古いバージョンは保持されるため 問題が発生した際にロールバックできますこれは障害発生時に非常に便利 です古い値を覚えておく必要がなく 以前のsecretにすぐに戻せますsecret、key、証明書の3種類すべて を同じファウルトに保存できますしかし環境ごとに分けるのがベスト プラクティスです開発、テスト、本番用にそれぞれ ファウルトを用意しましょうこれにより本番用secretの開発環境 でのご使用を防ぎ万が一の侵害時の影響範囲を抑えられますですが保存はあくまで半分に過ぎ ません真の問題は誰がアクセスできる かですアクセス制御の仕組みについてでは誰がアクセスできるかについて 説明しますキーファウルトには内部へのアクセス を制御する2つの方法があり選択は非常に重要です最初のモデルは従来のアクセス ポリシーですこれは古いやり方ですファウルトに対して直接ポリシー を作成しsecret、key、証明書といったデータ型ごとにユーザーやグループ へ権限を割り当てます問題はこれらのポリシーがファウルト に直接紐付いていることです複数のファウルトがある場合それぞれ 個別にポリシーを管理しなければなりません特徴性に欠けます現在マイクロソフトは基地のセキュリティ 上の問題があるためこれの使用を推奨していません特権ID管理をサポートしておらず 予期せぬ権限昇格経路を生む可能性があります2つ目のモデルはazure rbacロールベース のアクセス制御ですこれが現代的な方法ですエントラIDのIDを使用しazureの 他の権限管理手法と一貫していますストレージアカウントや仮想マシン へのアクセス権付与を知っていればキーファウルトへの付与 方法もすでに理解しているはずです同じシステム同じパターンですここで黄金率最小権限の原則 を上げます必要な最小限のアクセス権のみ を与えそれ以上は与えないことです読み取りのみ必要なユーザー には作成や削除の権限を与えてはいけません証明書の管理のみ必要なユーザー にキーへのアクセス権を与えてはいけません主要なロールを見ていきましょうキーファウルトリーダーがありますシークレットの一覧表示はできます が値の読み取りはできません次にキーファウルトシークレット ユーザーこれなら実際にシークレットの値 を読み取れますそしてキーファウルトシークレット オフィサーシークレットの作成更新削除が可能 ですパターンにお気づきでしょうか各ロールはファウルト自体ではなく ファウルト内のデータに対して特化していますでは後半なロールであるオーナー コントリビューター閲覧者と対比してみましょうこれらはリソースとしてのファウルト に適用されるものでありその内部データには適用されませんオーナーはファウルト全体を削除 できますコントリビューターはファウルト の設定を変更できますしかしこれらのロール単体では 内部のシークレットにアクセスすることはできませんそれは別の権限レイヤーであり ここが重要なポイントですアクセス制御は層上の契機のような ものですファウルト自体へのアクセス権という 第一の層と内部データへのアクセス権という第二の層が必要です両者は個別に許可される必要 があります初心者の多くは第一の層だけを 考え第二の層を忘れてしまいますそこに問題の種があるのですこれが最大のセキュリティミス です実はこういうことです多くの人はキーファウルトコントリビューター ロールを見て安全だと思い込みますコントリビューターという言葉 からファウルトの設定は管理できても内部のシークレットには触れ られないと想定するのですマイクロソフトのドキュメント 自体当初はまさにそう述べていましたこのロールではシークレットキー 証明書にはアクセスできませんとしかしそれは正確ではありませんキーファウルトコントリビューター のロールを持つユーザーはファウルトのアクセスポリシーを変更できて しまうのですもしそのファウルトで依然として レガシーなアクセスポリシーが使われていれば多くがそうですが 自分自身に全てのシークレットキー証明書への完全な読み取り 権限を付与できてしまいます特別な攻撃手法も修正すべき脆弱性 も必要ありません単に権限の仕組みがそうなっている だけですデータドッグのセキュリティ研究 者が2024年にこれを証明しました彼らはレガシーなアクセスポリシー を使用しているあらゆるファウルトにおいてコントリビューター がデータへのフルアクセス権まで昇格できることを示しましたマイクロソフトの反応は興味深い ものでした彼らはコントリビューターはアクセス ポリシーを管理するように設計されているためこれは脆弱性ではない と述べましたが一方でドキュメントを更新しこのロールが自らにデータ プレーンへのアクセス権を付与できる可能性があると明示的に 警告しましたつまりこれはキーファウルト自体 のバグではなく設定上の落とし穴なのですロール名が無害に聞こえるため 経験豊富なチームでさえもこれに引っかかりますコントリビューターという名前 はデータベースのパスワードを読み取れるような人には聞こえません が実際にはできてしまうのですそのリスクについて考えてみて ください攻撃者があなたのキーファウルト のコントリビューターロールを持つアカウントを侵害した場合彼らはファウルト を強行突破する必要はありません暗号を解読する必要さえありません彼らは単にアクセスポリシー を変更して自分に読み取り権限を与え保存されているすべてのシークレット 接続文字列APIキー証明書などお静かに流出させますアクセスポリシーの変更は通常 の管理作業であるためアラートがトリガーされない可能性もありますではどう修正すれば良いのでしょうかまずレガシーなアクセスポリシー の代わりにデータプレーンへのアクセスにAzure RBACを使用することですRBACを使用すればファウルトの 管理と内部のデータへのアクセスを分離できます次にキーファウルトコントリビュータ のロールはどうしても必要な人以外には絶対に付与しないでください3つ目にすでにそのロールを持つ ユーザーがいる場合は今すぐ監査を行ってくださいコントリビュータの代わりにキーファウルト シークレッツユーザーやキーファウルトシークレッツオフィサーといった より具体的なロールに置き換えてくださいこれに追い打ちをかける2つ目の 間違いは全てのシークレットを単一のファウルトに集約してしまう ことです開発テストステージング本番環境 そして全てのアプリケーションを一つのファウルトで管理していて そのファウルトが侵害されると全てが露呈してしまいますこれは単一障害点になりますマルチファウルト戦略について は後ほど詳しく説明しますが原則は単純です特にインフラ全体の鍵を握る ような場合全ての卵を一つのカゴに持ってはいけませんマネージドIDそれがゴールド スタンダードですではどうすれば正しく運用できる のでしょうかキーファウルトへの最適なアクセス 方法についてお話ししましょう根本的な問題がありますキーファウルトから視覚情報を 取得するにはアプリケーションの認証が必要ですが認証するには 視覚情報が必要ですアプリが視覚情報を取得するために 使う視覚情報はどこに保存すれば良いのでしょうかこれは鶏と卵の問題です以前の答えはクライアントシークレット 付きのサービスプリンシパルでしたがそのシークレットは設定ファイル や環境変数あるいはデプロイパイプラインなどどこかに置いておく必要があります結局同じ問題に逆戻りしてしまいます単にシークレットを別の場所に 移動させただけにすぎませんマネージドIDはこれを完全に解決 します仕組みはこうですウェブアプリや関数仮想マシン などのazureリソースでマネージドIDを有効にするとazureが自動的に エントラID上でそのリソースのIDを作成しますそのIDは完全にazureによって管理 されます視覚情報の作成もシークレット のローテーションも保存するものも何もありませんリソースはazureが認識するIDを 持つだけですIDには2種類ありますシステム割当マネージドIDは 特定の一つのリソースに紐付けられていますリソースを削除すればそのIDも 削除されますライフサイクルを共有するため 管理が簡素化されますユーザー割当マネージドIDは複数 のリソースに割当可能なスタンドアロンのIDですリソースとライフサイクルを共有 しないため複数のサービスで同じIDが必要な場合に便利です実際にどのように機能するか 見てみましょうwebアプリがキーファウルトから データベース接続文字列を読み取る必要があるとしますそのwebアプリでシステム割当マネージドID を有効にします次にそのIDに対してキーファウルト のキーファウルトシークレッツユーザーロールを付与しますこれだけですコード内に接続文字列はなく設定 ファイルにクライアントシークレットもありませんwebアプリはマネージドIDを使用 してキーファウルトで認証を行いazureが裏側でクレデンシャル の管理を全て処理しますこれはazureにおいてクレデンシャル レス認証に最も近い仕組みですこれはセキュリティにおけるゲーム チェンジャーです最も一般的な攻撃経路である クレデンシャルの盗難を排除できるからです盗むクレデンシャルがなければ 攻撃者が侵害できるものもありません実世界での例を挙げましょうシナプスのデータパイプライン がストレージアカウントにアクセスする必要があるとします昔の方法ではストレージアカウント のキーをパイプライン構成に保存していました誰かがそのパイプラインにアクセス できればキーを入手できてしまったわけですマネージドIDを使えばシナプス ワークスペースにIDが割り当てられますそのIDに対してストレージアカウント のキーが格納されているキーファウルトへのアクセス権を付与しますパイプラインは実行時にキーを 取得して使用しどこにも保存することはありませんコードにもパイプライン設定にも キーやシークレットは残りませんマネージドIDをRBAC及び最小権限 の原則と組み合わせることであらゆるAzureワークロードに安全な基盤 を付けますアプリケーションはクレデンシャル なしで認証を行います必要なものだけにアクセスし全て のアクセスはログに記録され監査可能ですこれはマイクロソフトがほぼ全て のシナリオで推奨しているパターンです使い始めればなぜ今まで他の方法 で言っていたのか不思議に思うはずですコストとマルチファウルト戦略 についてそれではコストについて話しましょうここで多くの人が驚かされますAzureキーファウルトは実際いくら かかるのでしょうか料金体系はシンプルですシークレットごとの保存量はありません保存するパスワードやAPIキー ごとに料金を支払う必要はないのですその代わり操作オペレーション ごとに課金されます標準ティアでは1万回の操作ごと に約3セントですシークレットの取得呼び出しが1回 の操作としてカウントされますシークレットの作成やファウルト の中身を一覧表示する操作も同様です一般的な中小規模のアプリケーション であれば月額は数セント程度に収まります文字通りわずかな金額ですオーセクレットマネージャー と比較してみましょうあちらは保存するだけでシークレット 1つにつき月額40セントに加えAPI呼び出しごとの追加料金が発生 します100個のシークレットがあれば一度も 読み取らなくても月額40ドルかかりますAzureキーファウルトなら100個の シークレットを標準的な頻度で使ってもコストは15セント程度です規模が大きくなればなるほど この差は急速に広がりますさてプレミアムティアという ものもありますこれは最高レベルの暗号化保証 が必要なワークロード向けにHSMバックアップのキーを追加 するものです金融取引やヘルスケアデータ政府 のシステムなどが対象です操作ごとのコストは高く高度な キータイプで1万回あたり約15セントとなりさらにHSMキーごとに月額 料金がかかりますしかしほとんどのアプリケーション にとって標準ティアで十分すぎるほどですここで人々が油断して驚かされる コストの落とし穴があります一般的なウェブアプリで少数の シークレットと月数千回の操作を行う場合キーハウルトのコスト は1ドル未満です設定中に飲むコーヒー代の方が 高くつくでしょうしかしコストよりも重要な戦略 がありますそれはいくつのハウルトを使う かということです賢明なアプローチはマルチハウルト 戦略を取ることです開発テストステージング本番環境 で別々のハウルトを使用してくださいこれが最も一般的な事故を防ぎますテストスクリプトを実行した 際に接続文字列が同じハウルトにあったため誤って本番データベース を読み取ってしまうといった事故です環境を分離すればそのようなミス は起こり得ませんビジネスユニットやコンプライアンス 領域ごとにも分けるべきです決済カードデータを扱うならその シークレットは専用のハウルトに入れてください一般的な業務ワークロードは別の ハウルトにヘルスケアデータはさらに別のハウルトに入れますこれは面倒にするためではなく被害 範囲を制限するためです仮に一つのハウルトが侵害されて もその中のシークレットしか漏洩しません他のインフラストラクチャは安全な ままですそして常に有効にすべき2つの組み込み の安全策があります論理削除とは誰かがシークレット を削除しても完全には消去されない仕組みです最大90日間選択した保持期間中 復元可能な状態になりますパージ保護はそれをさらに一歩進め たものです保持期間が過ぎるまで誰もハウルト やその中身を完全に削除することはできませんこれらを組み合わせることで セキュリティチームが頭を悩ませるような誤操作によるデータ損失 を防げます全体的な繋がりについてこれらすべてを統合して各要素 がどのように噛み合うかを見てみましょうキーファウルトは孤立した存在 ではありませんアジュールアーキテクチャにおける シークレットの中枢神経系ですシステム全体の流れを理解すれば すべてが納得できるはずですアプリケーションがシークレット を必要とするときの動きは以下の通りですアプリケーションはマネージドID を使用して要求を行いますそのIDはすでにエントラIDに登録 されていますリソースでマネージドIDを有効に した際アジュールが自動的に作成したもの ですエントラIDはそのIDが正当である ことを確認しリクエストをキーファウルトに渡 しますキーファウルトは割り当てられた RBAC権限をチェックしますそのIDがキーファウルトシークレット ユーザーのような適切なロールを持っていればシークレットが返されますこれらすべてがミリ秒単位で完了 しますアプリケーションが視覚情報 を見ることは一度もありませんパスワードを保存することさえ ありません必要な値を受け取るだけですさてどれだけのアジュールサービス がこれに連携できるかを考えてみてくださいアップサービスファンクションズ アクスデータファクトリーシナプスロジックアップスデブオプス パイプラインなどすべてがキーファウルトとの対話方法を知っていますウェブアプリがアプリケーション 設定でシークレットを直接参照するように構成できますデータファクトリーのパイプライン で実行時にキーファウルトからストレージアカウントのキーを取得 するよう設定することも可能ですキーファウルトcsiドライバー を使用してkubernetesクラスターがシークレットを取得するように 構成できますすべてのサービスが同じidシステム 同じrbacロール同じ監査ログを使用して一貫した方法で統合 されますci cdパターンは特に強力ですパイプラインはデプロイ時に キーファウルトからシークレットを取得しますこれらをパイプライン変数や リポジトリのシークレットに保存することはありませんデータベースのパスワードをローテーション する必要がある場合はキーファウルトで更新するだけです次回のパイプライン実行時に 新しい値が自動的に読み込まれますパイプラインの変更もコードの変更 も再デプロイも不要ですここですべてがうまく噛み合いますマネージドidとrbacでキーファウルト を設定すれば視覚情報管理について考える必要は完全になくなりますアプリケーションはそのまま機能 しますシークレットは誰にも気づかれる ことなくローテーションされます証明書も真夜中の緊急対応なしで 更新されますシステムがすべてバックグラウンド で処理しますこれこそが重要なセキュリティ 体制です境界となるのはネットワークでは なくidです仮想ネットワークの内側にいる か外側にいるかは問題ではありません重要なのは適切な権限を持つ 有効なidがあるかどうかですキーファウルトは設計上これを 強制しますすべてのアクセス要求はどこから発信 されたかに関わらずentra id認証とrbac認可を通過します そしてすべてがログに記録されますシークレットの読み取りキー 操作証明書の取得のすべてです誰が何をいつアクセスしたかを 確認できます不審な動きがあれば調査のための データが手元にありますこれはコンプライアンスやインシデント 対応そして環境内で何が起きているかを把握するために不可欠ですそれがすべての素晴らしさですキーファウルトentra idrbacmanaged id は統合された セキュリティフレームワークとして連携しますそれぞれの要素が互いを強化しますすべてが正しく設定されれば 自分で構築するよりも安全で運用もシンプルな資格情報管理システム が手に入ります実践的なヒントでは今すぐ具体的に何をすべき でしょうかこの知識を行動に移しましょう今週取り組めることは以下の 通りですまずは権限モデルから始めましょうポータルでキーファウルトを開き アクセス構成を確認してくださいファウルトアクセスポリシーと表示 されていればそれは古い方法です代わりにAzureロールベースのアクセス 制御RBACを使用する必要があります移行は簡単です権限モデルを切り替え既存の アクセスポリシーを持っていたユーザーにRBACロールを割り当て ます今日中に実行しましょうこれはマイクロソフトが推奨する 手法であり前述の調査結果がその理由を裏付けています次にキーファウルト貢献者ロール を持つアカウントを監査しますファウルトのアイアムブレードを開き 誰が貢献者アクセス権を持っているかを確認してくださいそのロールを持つ全員には妥当な 理由が必要ですほとんどの場合そうではありません共同作成者コントリビュータは より具体的な権限に置き換えましょうシークレットの読み取りのみが必要な 場合はキーファウルトシークレットユーザーを割り当てます管理が必要な場合はキーファウルト シークレットオフィサーを使用してください目標はその特権昇格の経路を完全に 塞ぐことです次にマネージドIDを活用しましょうキーファウルトへのアクセスが 必要な全てのアジュールサービスでこれを使うべきですウェブアプリファンクションデータ ファクトリーあるいは仮想マシンで依然としてクライアントシークレット 付きのサービスプリンシパルを使っているならマネージドIDに 切り替えてくださいその方がシンプルで安全ですし先ほど 取り上げた鶏と卵の問題も解決しますアジュールが裏側で認証情報の 管理を自動的に処理してくれますもう一つ全てのファウルトで 論理的な削除と消去保護を有効にしてください論理的な削除は新しいファウルト ではデフォルトで有効ですが消去保護は違います必ずオンにしましょうその設定により保持期間中に ファウルトやその中身を誰かが完全に削除するのを防げますこれまで多くのチームが致命的な ミスから救われてきましたここからがアクションプランです現在のシークレット管理方法を 見直してください構成ファイルや環境変数の中に残っている かコードに直処されているシークレットを一つ見つけましょう今週中にそれをキーハウルトへ 移行してくださいたった一つでいいのですどれほど簡単か分かれば残りの シークレットも全て移したくなるはずですセキュリティは一度設定して終わり ではありません継続的な習慣ですキーハウルトはその実践を容易に しますがそれは正しく使用した場合に限りますツールは揃っていますパターンは実証済みですあとはあなたがそれを実装する だけですシステムとはそういうものですキーハウルトはデジタル金庫 ですがその安全性は周囲に施すアクセス制御次第ですまずは私が説明した監査から 始めましょう権限モデルを確認してください共同作成者の割当てをチェック し今週中に一つのシークレットをファウルトへ移行しましょう今後も分かりやすいクラウド セキュリティのヒントを得るために登録を設定ファイルにシークレット を保存している知人にもぜひこの動画を共有してください