WEBVTT

00:00:00.000 --> 00:00:03.000
こんな状況を想像してみてください アプリケーションを構築していて

00:00:03.000 --> 00:00:05.900
サービス接続用のAPIキー データベースのパスワードあるいは

00:00:05.900 --> 00:00:07.400
ストレージアカウントキーが必要 になったとします

00:00:07.400 --> 00:00:10.920
そこでコード内に直接記述したり 設定ファイルや環境変数に保存

00:00:10.920 --> 00:00:11.360
したりします

00:00:11.360 --> 00:00:14.480
GitHubにプッシュしたりチームメイト とノートブックを共有したりする

00:00:14.480 --> 00:00:16.140
までは全て順調に動作します

00:00:16.140 --> 00:00:19.340
しかしその瞬間秘密の情報はもう 秘密ではなくなってしまいます

00:00:19.340 --> 00:00:22.580
もしそのコードが悪意のある手に 渡ればシステム全体が危険にさら

00:00:22.580 --> 00:00:22.920
されます

00:00:22.920 --> 00:00:26.100
そこでこの問題を解決するツール がアジュールキーファウルトです

00:00:26.100 --> 00:00:29.140
コード内に情報を残すことなく 安全に秘密を保管できる場所を

00:00:29.140 --> 00:00:29.620
提供します

00:00:29.620 --> 00:00:31.800
しかし多くの人が誤解している ことがあります

00:00:31.800 --> 00:00:34.520
キーファウルトを使っているから といって自動的に安全になるわけ

00:00:34.520 --> 00:00:35.000
ではありません

00:00:35.000 --> 00:00:38.660
どのように設定しアクセスを制御 し権限を割り当てるかが同じくらい

00:00:38.660 --> 00:00:39.160
重要です

00:00:39.160 --> 00:00:43.160
このエピソードの終わりにはキーファウルト の正体格納できるものアクセス

00:00:43.160 --> 00:00:46.360
の仕組みそして秘密が漏えいする 最大の過ちについて理解できる

00:00:46.360 --> 00:00:46.600
でしょう

00:00:46.600 --> 00:00:49.560
専門用語を使わず分かりやすい 言葉で必要な要点だけをお伝え

00:00:49.560 --> 00:00:49.760
します

00:00:49.760 --> 00:00:52.040
ではアジュールキーファウルトとは 一体何なのでしょうか

00:00:52.040 --> 00:00:53.540
アジュールキーファウルトとは何か

00:00:53.540 --> 00:00:55.280
最もシンプルな定義はこうです

00:00:55.280 --> 00:00:57.960
アジュールキーファウルトは秘密 情報を守るためのクラウドベース

00:00:57.960 --> 00:00:58.740
のデジタル金庫です

00:00:58.740 --> 00:01:03.140
APIキーデータベースのパスワード 接続文字列暗号化キー証明書

00:01:03.140 --> 00:01:05.420
を一元管理できるマイクロソフト のマネージドサービスです

00:01:05.420 --> 00:01:08.120
パッチ適用や稼働時間セキュリティ はアジュールが管理するため

00:01:08.120 --> 00:01:09.780
インフラを心配する必要はありません

00:01:09.780 --> 00:01:11.180
ただ利用するだけです

00:01:11.180 --> 00:01:12.920
オフィスビルを想像してみてください

00:01:12.920 --> 00:01:16.540
ワークステーションや会議室キャビネット がありますが地下には重要な

00:01:16.540 --> 00:01:18.360
ものを保管する頑丈な金庫室があります

00:01:18.360 --> 00:01:20.840
マスターキー現金法的な書類など です

00:01:20.840 --> 00:01:23.160
許可と認証がなければ誰もそこには 入れません

00:01:23.160 --> 00:01:25.500
そして誰かがドアを開けるたびに ログが記録されます

00:01:25.500 --> 00:01:26.760
それがキーファウルトです

00:01:26.760 --> 00:01:29.340
あなたのアジュールアーキテクチャ というビルの地下にある安全な

00:01:29.340 --> 00:01:29.820
部屋なのです

00:01:29.820 --> 00:01:32.100
では昔のやり方と比較してみましょう

00:01:32.100 --> 00:01:36.100
20年前データベースのパスワード が必要なときは設定ファイルや

00:01:36.100 --> 00:01:39.820
環境変数にハードコードするか 最悪の場合ソースコードに平文

00:01:39.820 --> 00:01:40.500
で残していました

00:01:40.500 --> 00:01:43.360
誰かがサーバーにアクセスできれば 全てが奪われていました

00:01:43.360 --> 00:01:46.480
またパスワードを変更する必要がある ときは至る所を更新しなければ

00:01:46.480 --> 00:01:46.940
なりませんでした

00:01:46.940 --> 00:01:49.780
全ての設定ファイル全ての環境 全てのデプロイメントでです

00:01:49.780 --> 00:01:50.780
まさに悪夢でした

00:01:50.780 --> 00:01:52.580
キーファウルトはそれを全て変え ます

00:01:52.580 --> 00:01:56.180
コードや設定ファイルに秘密を散らばせる 代わりに一つの場所に集約

00:01:56.180 --> 00:01:56.860
して保管します

00:01:56.860 --> 00:02:00.060
アプリケーションが必要なとき にだけ実行時にそれを要求する

00:02:00.060 --> 00:02:00.340
のです

00:02:00.340 --> 00:02:03.440
全てが一元管理されているため 一箇所でシークレットをローテーション

00:02:03.440 --> 00:02:05.940
すればそれを使用する全ての アプリケーションがコード変更

00:02:05.940 --> 00:02:08.720
や再デプロイなしで自動的に新しい 値を取得できます

00:02:08.720 --> 00:02:11.240
しかし重要なのはキーファウルト は単なるアプリ向けのパスワード

00:02:11.240 --> 00:02:12.300
マネージャーではないということ です

00:02:12.300 --> 00:02:14.420
これは中核となるセキュリティ サービスなのです

00:02:14.420 --> 00:02:16.340
あらゆるアジュールサービスと統合 できます

00:02:16.340 --> 00:02:19.000
アップサービスファンクションズ アクスデータファクトリーシナプス

00:02:19.000 --> 00:02:21.540
ロジックアップスデブオプスパイプライン など全てがキーファウルトとの

00:02:21.540 --> 00:02:22.280
連携に対応しています

00:02:22.280 --> 00:02:24.660
これが皆さんのセキュアなクラウド アーキテクチャのバックボーン

00:02:24.660 --> 00:02:25.040
となります

00:02:25.040 --> 00:02:28.100
一度正しく設定してしまえば認証 情報の管理について考える必要

00:02:28.100 --> 00:02:28.880
は完全になくなります

00:02:28.880 --> 00:02:30.420
何が保存できるのでしょうか

00:02:30.420 --> 00:02:33.140
キーファウルトが何であるか理解 できたところで実際に何を入れる

00:02:33.140 --> 00:02:34.300
ことができるのかを見ていきましょう

00:02:34.300 --> 00:02:35.880
主なカテゴリーは3つあります

00:02:35.880 --> 00:02:38.320
シークレットキーそして証明書 です

00:02:38.320 --> 00:02:41.180
それぞれ役割が異なりその違い を理解することがキーファウルト

00:02:41.180 --> 00:02:42.460
を正しく活用する鍵となります

00:02:42.460 --> 00:02:44.220
まずはシークレットから始め ましょう

00:02:44.220 --> 00:02:46.420
これは最も一般的に保存される ものです

00:02:46.420 --> 00:02:50.280
シークレットとは接続文字列 apiキー データベースのパスワードストレージ

00:02:50.280 --> 00:02:52.640
アカウントキーなどアプリが他 のサービスと通信するために必要

00:02:52.640 --> 00:02:54.060
な日常的な認証情報のすべて です

00:02:54.060 --> 00:02:57.020
これらをコードや設定ファイル に記述する代わりにキーファウルト

00:02:57.020 --> 00:02:57.620
に保存します

00:02:57.620 --> 00:03:00.260
アプリは実行時にこれらを取得 するため誰にもプレーンテキスト

00:03:00.260 --> 00:03:01.200
で晒されることはありません

00:03:01.200 --> 00:03:03.520
デジタルファイリングキャビネット にある鍵付きの引き出しのような

00:03:03.520 --> 00:03:04.320
ものだと考えてください

00:03:04.320 --> 00:03:05.340
次はキーです

00:03:05.340 --> 00:03:08.020
これは保存データデータアドレスト を暗号化するための暗号化キー

00:03:08.020 --> 00:03:08.200
です

00:03:08.200 --> 00:03:11.400
azureストレージsqlデータベースあるいは 仮想マシンのディスク暗号化

00:03:11.400 --> 00:03:13.900
にカスタマー管理キーを使用する 場合それらのキーをキーファウルト

00:03:13.900 --> 00:03:14.420
に保存できます

00:03:14.420 --> 00:03:17.520
これにより誰がいつそれを使用 できるかを完全に制御できます

00:03:17.520 --> 00:03:19.760
コンプライアンス上の理由で ハードウェアベースのキーが必要

00:03:19.760 --> 00:03:22.340
な場合もプレミアムティアの hsm 保護機能が対応します

00:03:22.340 --> 00:03:23.780
最後は証明書です

00:03:23.780 --> 00:03:27.860
webアプリapi内部サービス向け のtlsおよびssl証明書です

00:03:27.860 --> 00:03:30.580
キーファウルトはそれらを保存 しライフサイクルを管理し期限

00:03:30.580 --> 00:03:32.280
が近づけば自動更新することさえ 可能です

00:03:32.280 --> 00:03:35.300
日曜日の午前3時に証明書の期限 が切れて困った経験がある人に

00:03:35.300 --> 00:03:36.960
とってはまさに救世主と言える でしょう

00:03:36.960 --> 00:03:38.400
具体的な例を挙げます

00:03:38.400 --> 00:03:41.320
データベースの接続文字列と サードパーティサービスのapi

00:03:41.320 --> 00:03:43.320
キーを必要とするwebアプリを 創造してください

00:03:43.320 --> 00:03:46.680
従来の方法では両方をアプリ 設定のjsonファイルに記述していました

00:03:46.680 --> 00:03:49.320
もしそのファイルがリポジトリ に残ってしまえばコードにアクセス

00:03:49.320 --> 00:03:52.020
できる全員がデータベースの認証 情報を見ることができてしまいます

00:03:52.020 --> 00:03:54.860
キーファウルトを使えば両方の 値をsecretとして保存します

00:03:54.860 --> 00:03:57.240
アプリは起動時にこれらを取得 するためソースコード上に表示される

00:03:57.240 --> 00:03:57.780
ことはありません

00:03:57.780 --> 00:03:59.620
データベースのパスワードを ローテーションする必要があります

00:03:59.620 --> 00:04:01.380
かキーファウルトで更新するだけ です

00:04:01.380 --> 00:04:04.140
次の再起動時にアプリは自動的 に新しい値を取得します

00:04:04.140 --> 00:04:06.140
コードの変更も再デプロイも不要 です

00:04:06.140 --> 00:04:08.500
意外と知られていないのがバージョン 管理機能が組み込まれている点

00:04:08.500 --> 00:04:09.500
です

00:04:09.500 --> 00:04:11.500
secretを更新してもキーファウルトは 古い値を上書きしません

00:04:11.500 --> 00:04:13.060
新しいバージョンを作成します

00:04:13.060 --> 00:04:15.860
古いバージョンは保持されるため 問題が発生した際にロールバック

00:04:15.860 --> 00:04:16.860
できます

00:04:16.860 --> 00:04:18.580
これは障害発生時に非常に便利 です

00:04:18.580 --> 00:04:22.900
古い値を覚えておく必要がなく 以前のsecretにすぐに戻せます

00:04:22.900 --> 00:04:27.140
secret、key、証明書の3種類すべて を同じファウルトに保存できます

00:04:27.140 --> 00:04:30.100
しかし環境ごとに分けるのがベスト プラクティスです

00:04:30.100 --> 00:04:33.740
開発、テスト、本番用にそれぞれ ファウルトを用意しましょう

00:04:33.740 --> 00:04:38.680
これにより本番用secretの開発環境 でのご使用を防ぎ万が一の侵害時

00:04:38.680 --> 00:04:40.200
の影響範囲を抑えられます

00:04:40.200 --> 00:04:42.540
ですが保存はあくまで半分に過ぎ ません

00:04:42.540 --> 00:04:44.940
真の問題は誰がアクセスできる かです

00:04:44.940 --> 00:04:46.580
アクセス制御の仕組みについて

00:04:46.580 --> 00:04:48.820
では誰がアクセスできるかについて 説明します

00:04:48.820 --> 00:04:52.020
キーファウルトには内部へのアクセス を制御する2つの方法があり選択

00:04:52.020 --> 00:04:53.060
は非常に重要です

00:04:53.060 --> 00:04:55.620
最初のモデルは従来のアクセス ポリシーです

00:04:55.620 --> 00:04:57.120
これは古いやり方です

00:04:57.120 --> 00:05:01.720
ファウルトに対して直接ポリシー を作成しsecret、key、証明書といった

00:05:01.720 --> 00:05:04.300
データ型ごとにユーザーやグループ へ権限を割り当てます

00:05:04.300 --> 00:05:07.460
問題はこれらのポリシーがファウルト に直接紐付いていることです

00:05:07.460 --> 00:05:10.340
複数のファウルトがある場合それぞれ 個別にポリシーを管理しなければ

00:05:10.340 --> 00:05:11.340
なりません

00:05:11.340 --> 00:05:12.340
特徴性に欠けます

00:05:12.340 --> 00:05:15.780
現在マイクロソフトは基地のセキュリティ 上の問題があるためこれの使用

00:05:15.780 --> 00:05:16.780
を推奨していません

00:05:16.780 --> 00:05:20.720
特権ID管理をサポートしておらず 予期せぬ権限昇格経路を生む可能性

00:05:20.720 --> 00:05:21.720
があります

00:05:21.720 --> 00:05:24.860
2つ目のモデルはazure rbacロールベース のアクセス制御です

00:05:24.860 --> 00:05:26.520
これが現代的な方法です

00:05:26.520 --> 00:05:30.800
エントラIDのIDを使用しazureの 他の権限管理手法と一貫しています

00:05:30.800 --> 00:05:33.480
ストレージアカウントや仮想マシン へのアクセス権付与を知って

00:05:33.480 --> 00:05:36.200
いればキーファウルトへの付与 方法もすでに理解しているはず

00:05:36.200 --> 00:05:36.480
です

00:05:36.480 --> 00:05:38.100
同じシステム同じパターンです

00:05:38.100 --> 00:05:40.900
ここで黄金率最小権限の原則 を上げます

00:05:40.900 --> 00:05:44.220
必要な最小限のアクセス権のみ を与えそれ以上は与えないことです

00:05:44.220 --> 00:05:47.380
読み取りのみ必要なユーザー には作成や削除の権限を与えて

00:05:47.380 --> 00:05:47.820
はいけません

00:05:47.820 --> 00:05:50.880
証明書の管理のみ必要なユーザー にキーへのアクセス権を与えて

00:05:50.880 --> 00:05:51.320
はいけません

00:05:51.320 --> 00:05:53.020
主要なロールを見ていきましょう

00:05:53.020 --> 00:05:54.600
キーファウルトリーダーがあります

00:05:54.600 --> 00:05:57.160
シークレットの一覧表示はできます が値の読み取りはできません

00:05:57.160 --> 00:05:59.040
次にキーファウルトシークレット ユーザー

00:05:59.040 --> 00:06:01.120
これなら実際にシークレットの値 を読み取れます

00:06:01.120 --> 00:06:03.180
そしてキーファウルトシークレット オフィサー

00:06:03.180 --> 00:06:05.660
シークレットの作成更新削除が可能 です

00:06:05.660 --> 00:06:07.180
パターンにお気づきでしょうか

00:06:07.180 --> 00:06:09.880
各ロールはファウルト自体ではなく ファウルト内のデータに対して

00:06:09.880 --> 00:06:10.440
特化しています

00:06:10.440 --> 00:06:13.080
では後半なロールであるオーナー コントリビューター閲覧者

00:06:13.080 --> 00:06:13.720
と対比してみましょう

00:06:13.720 --> 00:06:16.080
これらはリソースとしてのファウルト に適用されるものでありその内部

00:06:16.080 --> 00:06:16.860
データには適用されません

00:06:16.860 --> 00:06:18.760
オーナーはファウルト全体を削除 できます

00:06:18.760 --> 00:06:21.180
コントリビューターはファウルト の設定を変更できます

00:06:21.180 --> 00:06:24.200
しかしこれらのロール単体では 内部のシークレットにアクセス

00:06:24.200 --> 00:06:24.960
することはできません

00:06:24.960 --> 00:06:27.840
それは別の権限レイヤーであり ここが重要なポイントです

00:06:27.840 --> 00:06:30.080
アクセス制御は層上の契機のような ものです

00:06:30.080 --> 00:06:33.520
ファウルト自体へのアクセス権という 第一の層と内部データへのアクセス

00:06:33.520 --> 00:06:34.960
権という第二の層が必要です

00:06:34.960 --> 00:06:37.020
両者は個別に許可される必要 があります

00:06:37.020 --> 00:06:40.200
初心者の多くは第一の層だけを 考え第二の層を忘れてしまいます

00:06:40.200 --> 00:06:41.840
そこに問題の種があるのです

00:06:41.840 --> 00:06:43.480
これが最大のセキュリティミス です

00:06:43.480 --> 00:06:44.880
実はこういうことです

00:06:44.880 --> 00:06:47.580
多くの人はキーファウルトコントリビューター ロールを見て安全だと思い込みます

00:06:47.580 --> 00:06:49.860
コントリビューターという言葉 からファウルトの設定は管理でき

00:06:49.860 --> 00:06:51.860
ても内部のシークレットには触れ られないと想定するのです

00:06:51.860 --> 00:06:54.620
マイクロソフトのドキュメント 自体当初はまさにそう述べていました

00:06:54.620 --> 00:06:57.880
このロールではシークレットキー 証明書にはアクセスできません

00:06:57.880 --> 00:07:00.020
としかしそれは正確ではありません

00:07:00.020 --> 00:07:02.680
キーファウルトコントリビューター のロールを持つユーザーはファウルト

00:07:02.680 --> 00:07:04.420
のアクセスポリシーを変更できて しまうのです

00:07:04.420 --> 00:07:06.620
もしそのファウルトで依然として レガシーなアクセスポリシーが

00:07:06.620 --> 00:07:09.520
使われていれば多くがそうですが 自分自身に全てのシークレット

00:07:09.520 --> 00:07:12.220
キー証明書への完全な読み取り 権限を付与できてしまいます

00:07:12.220 --> 00:07:15.160
特別な攻撃手法も修正すべき脆弱性 も必要ありません

00:07:15.160 --> 00:07:17.160
単に権限の仕組みがそうなっている だけです

00:07:17.160 --> 00:07:20.080
データドッグのセキュリティ研究 者が2024年にこれを証明しました

00:07:20.080 --> 00:07:22.600
彼らはレガシーなアクセスポリシー を使用しているあらゆるファウルト

00:07:22.600 --> 00:07:24.540
においてコントリビューター がデータへのフルアクセス権まで

00:07:24.540 --> 00:07:25.520
昇格できることを示しました

00:07:25.520 --> 00:07:27.720
マイクロソフトの反応は興味深い ものでした

00:07:27.720 --> 00:07:30.100
彼らはコントリビューターはアクセス ポリシーを管理するように設計

00:07:30.100 --> 00:07:32.740
されているためこれは脆弱性ではない と述べましたが一方でドキュメント

00:07:32.740 --> 00:07:35.000
を更新しこのロールが自らにデータ プレーンへのアクセス権を付与

00:07:35.000 --> 00:07:36.460
できる可能性があると明示的に 警告しました

00:07:36.460 --> 00:07:39.580
つまりこれはキーファウルト自体 のバグではなく設定上の落とし穴

00:07:39.580 --> 00:07:39.940
なのです

00:07:39.940 --> 00:07:42.840
ロール名が無害に聞こえるため 経験豊富なチームでさえもこれに

00:07:42.840 --> 00:07:43.300
引っかかります

00:07:43.300 --> 00:07:45.440
コントリビューターという名前 はデータベースのパスワードを

00:07:45.440 --> 00:07:47.640
読み取れるような人には聞こえません が実際にはできてしまうのです

00:07:47.640 --> 00:07:49.400
そのリスクについて考えてみて ください

00:07:49.400 --> 00:07:52.220
攻撃者があなたのキーファウルト のコントリビューターロールを持つアカウント

00:07:52.220 --> 00:07:54.960
を侵害した場合彼らはファウルト を強行突破する必要はありません

00:07:54.960 --> 00:07:56.920
暗号を解読する必要さえありません

00:07:56.920 --> 00:07:59.780
彼らは単にアクセスポリシー を変更して自分に読み取り権限を

00:07:59.780 --> 00:08:04.340
与え保存されているすべてのシークレット 接続文字列APIキー証明書など

00:08:04.340 --> 00:08:05.500
お静かに流出させます

00:08:05.500 --> 00:08:08.420
アクセスポリシーの変更は通常 の管理作業であるためアラート

00:08:08.420 --> 00:08:09.780
がトリガーされない可能性もあります

00:08:09.780 --> 00:08:11.660
ではどう修正すれば良いのでしょうか

00:08:11.660 --> 00:08:14.120
まずレガシーなアクセスポリシー の代わりにデータプレーンへのアクセス

00:08:14.120 --> 00:08:15.540
にAzure RBACを使用することです

00:08:15.540 --> 00:08:18.160
RBACを使用すればファウルトの 管理と内部のデータへのアクセス

00:08:18.160 --> 00:08:18.600
を分離できます

00:08:18.600 --> 00:08:21.360
次にキーファウルトコントリビュータ のロールはどうしても必要な人

00:08:21.360 --> 00:08:22.580
以外には絶対に付与しないでください

00:08:22.580 --> 00:08:25.640
3つ目にすでにそのロールを持つ ユーザーがいる場合は今すぐ監査

00:08:25.640 --> 00:08:26.220
を行ってください

00:08:26.220 --> 00:08:28.820
コントリビュータの代わりにキーファウルト シークレッツユーザーやキーファウルト

00:08:28.820 --> 00:08:31.080
シークレッツオフィサーといった より具体的なロールに置き換えてください

00:08:31.080 --> 00:08:33.980
これに追い打ちをかける2つ目の 間違いは全てのシークレットを

00:08:33.980 --> 00:08:35.640
単一のファウルトに集約してしまう ことです

00:08:35.640 --> 00:08:39.440
開発テストステージング本番環境 そして全てのアプリケーションを

00:08:39.440 --> 00:08:42.060
一つのファウルトで管理していて そのファウルトが侵害されると

00:08:42.060 --> 00:08:43.340
全てが露呈してしまいます

00:08:43.340 --> 00:08:45.160
これは単一障害点になります

00:08:45.160 --> 00:08:48.280
マルチファウルト戦略について は後ほど詳しく説明しますが原則

00:08:48.280 --> 00:08:48.860
は単純です

00:08:48.860 --> 00:08:52.420
特にインフラ全体の鍵を握る ような場合全ての卵を一つの

00:08:52.420 --> 00:08:53.360
カゴに持ってはいけません

00:08:53.360 --> 00:08:55.700
マネージドIDそれがゴールド スタンダードです

00:08:55.700 --> 00:08:57.660
ではどうすれば正しく運用できる のでしょうか

00:08:57.660 --> 00:08:59.840
キーファウルトへの最適なアクセス 方法についてお話ししましょう

00:08:59.840 --> 00:09:01.320
根本的な問題があります

00:09:01.320 --> 00:09:03.600
キーファウルトから視覚情報を 取得するにはアプリケーションの

00:09:03.600 --> 00:09:06.240
認証が必要ですが認証するには 視覚情報が必要です

00:09:06.240 --> 00:09:09.180
アプリが視覚情報を取得するために 使う視覚情報はどこに保存すれば

00:09:09.180 --> 00:09:09.700
良いのでしょうか

00:09:09.700 --> 00:09:11.520
これは鶏と卵の問題です

00:09:11.520 --> 00:09:14.120
以前の答えはクライアントシークレット 付きのサービスプリンシパルでした

00:09:14.120 --> 00:09:17.680
がそのシークレットは設定ファイル や環境変数あるいはデプロイパイプライン

00:09:17.680 --> 00:09:19.300
などどこかに置いておく必要があります

00:09:19.300 --> 00:09:21.520
結局同じ問題に逆戻りしてしまいます

00:09:21.520 --> 00:09:23.680
単にシークレットを別の場所に 移動させただけにすぎません

00:09:23.680 --> 00:09:25.860
マネージドIDはこれを完全に解決 します

00:09:25.860 --> 00:09:26.920
仕組みはこうです

00:09:26.920 --> 00:09:30.320
ウェブアプリや関数仮想マシン などのazureリソースでマネージド

00:09:30.320 --> 00:09:34.200
IDを有効にするとazureが自動的に エントラID上でそのリソースの

00:09:34.200 --> 00:09:35.200
IDを作成します

00:09:35.200 --> 00:09:37.920
そのIDは完全にazureによって管理 されます

00:09:37.920 --> 00:09:41.100
視覚情報の作成もシークレット のローテーションも保存するもの

00:09:41.100 --> 00:09:41.800
も何もありません

00:09:41.800 --> 00:09:44.600
リソースはazureが認識するIDを 持つだけです

00:09:44.600 --> 00:09:46.020
IDには2種類あります

00:09:46.020 --> 00:09:49.300
システム割当マネージドIDは 特定の一つのリソースに紐付け

00:09:49.300 --> 00:09:49.720
られています

00:09:49.720 --> 00:09:52.480
リソースを削除すればそのIDも 削除されます

00:09:52.480 --> 00:09:55.480
ライフサイクルを共有するため 管理が簡素化されます

00:09:55.480 --> 00:09:59.760
ユーザー割当マネージドIDは複数 のリソースに割当可能なスタンドアロン

00:09:59.760 --> 00:10:00.420
のIDです

00:10:00.420 --> 00:10:03.480
リソースとライフサイクルを共有 しないため複数のサービスで

00:10:03.480 --> 00:10:05.360
同じIDが必要な場合に便利です

00:10:05.360 --> 00:10:07.600
実際にどのように機能するか 見てみましょう

00:10:07.600 --> 00:10:10.380
webアプリがキーファウルトから データベース接続文字列を読み

00:10:10.380 --> 00:10:11.460
取る必要があるとします

00:10:11.460 --> 00:10:14.680
そのwebアプリでシステム割当マネージドID を有効にします

00:10:14.680 --> 00:10:18.320
次にそのIDに対してキーファウルト のキーファウルトシークレッツユーザーロール

00:10:18.320 --> 00:10:18.840
を付与します

00:10:18.840 --> 00:10:19.720
これだけです

00:10:19.720 --> 00:10:22.760
コード内に接続文字列はなく設定 ファイルにクライアントシークレット

00:10:22.760 --> 00:10:23.200
もありません

00:10:23.200 --> 00:10:26.400
webアプリはマネージドIDを使用 してキーファウルトで認証を行い

00:10:26.400 --> 00:10:28.920
azureが裏側でクレデンシャル の管理を全て処理します

00:10:28.920 --> 00:10:32.520
これはazureにおいてクレデンシャル レス認証に最も近い仕組みです

00:10:32.520 --> 00:10:34.760
これはセキュリティにおけるゲーム チェンジャーです

00:10:34.760 --> 00:10:37.980
最も一般的な攻撃経路である クレデンシャルの盗難を排除できる

00:10:37.980 --> 00:10:38.340
からです

00:10:38.340 --> 00:10:41.800
盗むクレデンシャルがなければ 攻撃者が侵害できるものもありません

00:10:41.800 --> 00:10:43.620
実世界での例を挙げましょう

00:10:43.620 --> 00:10:46.340
シナプスのデータパイプライン がストレージアカウントにアクセス

00:10:46.340 --> 00:10:47.420
する必要があるとします

00:10:47.420 --> 00:10:50.820
昔の方法ではストレージアカウント のキーをパイプライン構成に保存

00:10:50.820 --> 00:10:51.200
していました

00:10:51.200 --> 00:10:53.980
誰かがそのパイプラインにアクセス できればキーを入手できてしまった

00:10:53.980 --> 00:10:54.320
わけです

00:10:54.320 --> 00:10:57.380
マネージドIDを使えばシナプス ワークスペースにIDが割り当てられ

00:10:57.380 --> 00:10:57.560
ます

00:10:57.560 --> 00:11:00.840
そのIDに対してストレージアカウント のキーが格納されているキーファウルト

00:11:00.840 --> 00:11:01.820
へのアクセス権を付与します

00:11:01.820 --> 00:11:05.220
パイプラインは実行時にキーを 取得して使用しどこにも保存する

00:11:05.220 --> 00:11:05.880
ことはありません

00:11:05.880 --> 00:11:08.960
コードにもパイプライン設定にも キーやシークレットは残りません

00:11:08.960 --> 00:11:12.880
マネージドIDをRBAC及び最小権限 の原則と組み合わせることであらゆる

00:11:12.880 --> 00:11:14.540
Azureワークロードに安全な基盤 を付けます

00:11:14.540 --> 00:11:16.980
アプリケーションはクレデンシャル なしで認証を行います

00:11:16.980 --> 00:11:20.180
必要なものだけにアクセスし全て のアクセスはログに記録され監査

00:11:20.180 --> 00:11:20.600
可能です

00:11:20.600 --> 00:11:23.540
これはマイクロソフトがほぼ全て のシナリオで推奨しているパターン

00:11:23.540 --> 00:11:23.740
です

00:11:23.740 --> 00:11:26.880
使い始めればなぜ今まで他の方法 で言っていたのか不思議に思う

00:11:26.880 --> 00:11:27.200
はずです

00:11:27.200 --> 00:11:29.100
コストとマルチファウルト戦略 について

00:11:29.100 --> 00:11:31.040
それではコストについて話しましょう

00:11:31.040 --> 00:11:32.740
ここで多くの人が驚かされます

00:11:32.740 --> 00:11:34.920
Azureキーファウルトは実際いくら かかるのでしょうか

00:11:34.920 --> 00:11:36.300
料金体系はシンプルです

00:11:36.300 --> 00:11:37.800
シークレットごとの保存量はありません

00:11:37.800 --> 00:11:40.280
保存するパスワードやAPIキー ごとに料金を支払う必要はないの

00:11:40.280 --> 00:11:40.460
です

00:11:40.460 --> 00:11:42.420
その代わり操作オペレーション ごとに課金されます

00:11:42.420 --> 00:11:45.140
標準ティアでは1万回の操作ごと に約3セントです

00:11:45.140 --> 00:11:47.660
シークレットの取得呼び出しが1回 の操作としてカウントされます

00:11:47.660 --> 00:11:50.440
シークレットの作成やファウルト の中身を一覧表示する操作も同様です

00:11:50.440 --> 00:11:53.360
一般的な中小規模のアプリケーション であれば月額は数セント程度に

00:11:53.360 --> 00:11:53.740
収まります

00:11:53.740 --> 00:11:55.480
文字通りわずかな金額です

00:11:55.480 --> 00:11:57.520
オーセクレットマネージャー と比較してみましょう

00:11:57.520 --> 00:12:00.220
あちらは保存するだけでシークレット 1つにつき月額40セントに加え

00:12:00.220 --> 00:12:02.160
API呼び出しごとの追加料金が発生 します

00:12:02.160 --> 00:12:05.440
100個のシークレットがあれば一度も 読み取らなくても月額40ドルかかります

00:12:05.440 --> 00:12:08.320
Azureキーファウルトなら100個の シークレットを標準的な頻度で使っても

00:12:08.320 --> 00:12:09.440
コストは15セント程度です

00:12:09.440 --> 00:12:11.660
規模が大きくなればなるほど この差は急速に広がります

00:12:11.660 --> 00:12:13.420
さてプレミアムティアという ものもあります

00:12:13.420 --> 00:12:16.080
これは最高レベルの暗号化保証 が必要なワークロード向けに

00:12:16.080 --> 00:12:17.800
HSMバックアップのキーを追加 するものです

00:12:17.800 --> 00:12:21.220
金融取引やヘルスケアデータ政府 のシステムなどが対象です

00:12:21.220 --> 00:12:25.180
操作ごとのコストは高く高度な キータイプで1万回あたり約15セント

00:12:25.180 --> 00:12:28.380
となりさらにHSMキーごとに月額 料金がかかります

00:12:28.380 --> 00:12:31.540
しかしほとんどのアプリケーション にとって標準ティアで十分すぎる

00:12:31.540 --> 00:12:31.920
ほどです

00:12:31.920 --> 00:12:34.980
ここで人々が油断して驚かされる コストの落とし穴があります

00:12:34.980 --> 00:12:38.000
一般的なウェブアプリで少数の シークレットと月数千回の操作

00:12:38.000 --> 00:12:40.300
を行う場合キーハウルトのコスト は1ドル未満です

00:12:40.300 --> 00:12:42.920
設定中に飲むコーヒー代の方が 高くつくでしょう

00:12:42.920 --> 00:12:45.160
しかしコストよりも重要な戦略 があります

00:12:45.160 --> 00:12:47.180
それはいくつのハウルトを使う かということです

00:12:47.180 --> 00:12:49.480
賢明なアプローチはマルチハウルト 戦略を取ることです

00:12:49.480 --> 00:12:52.640
開発テストステージング本番環境 で別々のハウルトを使用してください

00:12:52.640 --> 00:12:54.660
これが最も一般的な事故を防ぎます

00:12:54.660 --> 00:12:57.300
テストスクリプトを実行した 際に接続文字列が同じハウルト

00:12:57.300 --> 00:12:59.740
にあったため誤って本番データベース を読み取ってしまうといった事故

00:12:59.740 --> 00:12:59.940
です

00:12:59.940 --> 00:13:02.660
環境を分離すればそのようなミス は起こり得ません

00:13:02.660 --> 00:13:05.680
ビジネスユニットやコンプライアンス 領域ごとにも分けるべきです

00:13:05.680 --> 00:13:08.700
決済カードデータを扱うならその シークレットは専用のハウルト

00:13:08.700 --> 00:13:09.240
に入れてください

00:13:09.240 --> 00:13:11.840
一般的な業務ワークロードは別の ハウルトにヘルスケアデータは

00:13:11.840 --> 00:13:12.820
さらに別のハウルトに入れます

00:13:12.820 --> 00:13:15.800
これは面倒にするためではなく被害 範囲を制限するためです

00:13:15.800 --> 00:13:18.940
仮に一つのハウルトが侵害されて もその中のシークレットしか漏洩

00:13:18.940 --> 00:13:19.220
しません

00:13:19.220 --> 00:13:21.260
他のインフラストラクチャは安全な ままです

00:13:21.260 --> 00:13:23.900
そして常に有効にすべき2つの組み込み の安全策があります

00:13:23.900 --> 00:13:27.220
論理削除とは誰かがシークレット を削除しても完全には消去されない

00:13:27.220 --> 00:13:27.660
仕組みです

00:13:27.660 --> 00:13:31.840
最大90日間選択した保持期間中 復元可能な状態になります

00:13:31.840 --> 00:13:34.580
パージ保護はそれをさらに一歩進め たものです

00:13:34.580 --> 00:13:38.080
保持期間が過ぎるまで誰もハウルト やその中身を完全に削除することは

00:13:38.080 --> 00:13:38.440
できません

00:13:38.440 --> 00:13:41.180
これらを組み合わせることで セキュリティチームが頭を悩ませる

00:13:41.180 --> 00:13:42.900
ような誤操作によるデータ損失 を防げます

00:13:42.900 --> 00:13:44.420
全体的な繋がりについて

00:13:44.420 --> 00:13:46.820
これらすべてを統合して各要素 がどのように噛み合うかを見て

00:13:46.820 --> 00:13:47.100
みましょう

00:13:47.100 --> 00:13:49.040
キーファウルトは孤立した存在 ではありません

00:13:49.040 --> 00:13:52.080
アジュールアーキテクチャにおける シークレットの中枢神経系です

00:13:52.080 --> 00:13:55.320
システム全体の流れを理解すれば すべてが納得できるはずです

00:13:55.320 --> 00:13:57.560
アプリケーションがシークレット を必要とするときの動きは

00:13:57.560 --> 00:13:58.160
以下の通りです

00:13:58.160 --> 00:14:00.860
アプリケーションはマネージドID を使用して要求を行います

00:14:00.860 --> 00:14:03.540
そのIDはすでにエントラIDに登録 されています

00:14:03.540 --> 00:14:05.700
リソースでマネージドIDを有効に した際

00:14:05.700 --> 00:14:07.720
アジュールが自動的に作成したもの です

00:14:07.720 --> 00:14:10.520
エントラIDはそのIDが正当である ことを確認し

00:14:10.520 --> 00:14:12.280
リクエストをキーファウルトに渡 します

00:14:12.280 --> 00:14:15.120
キーファウルトは割り当てられた RBAC権限をチェックします

00:14:15.120 --> 00:14:17.820
そのIDがキーファウルトシークレット ユーザーのような適切なロール

00:14:17.820 --> 00:14:19.200
を持っていればシークレットが返されます

00:14:19.200 --> 00:14:21.000
これらすべてがミリ秒単位で完了 します

00:14:21.000 --> 00:14:22.940
アプリケーションが視覚情報 を見ることは一度もありません

00:14:22.940 --> 00:14:24.480
パスワードを保存することさえ ありません

00:14:24.480 --> 00:14:26.080
必要な値を受け取るだけです

00:14:26.080 --> 00:14:28.440
さてどれだけのアジュールサービス がこれに連携できるかを考えて

00:14:28.440 --> 00:14:28.760
みてください

00:14:28.760 --> 00:14:31.060
アップサービスファンクションズ アクスデータファクトリー

00:14:31.060 --> 00:14:33.560
シナプスロジックアップスデブオプス パイプラインなどすべてが

00:14:33.560 --> 00:14:34.760
キーファウルトとの対話方法を知っています

00:14:34.760 --> 00:14:37.940
ウェブアプリがアプリケーション 設定でシークレットを直接参照する

00:14:37.940 --> 00:14:38.800
ように構成できます

00:14:38.800 --> 00:14:41.420
データファクトリーのパイプライン で実行時にキーファウルトから

00:14:41.420 --> 00:14:43.860
ストレージアカウントのキーを取得 するよう設定することも可能です

00:14:43.860 --> 00:14:46.660
キーファウルトcsiドライバー を使用してkubernetesクラスター

00:14:46.660 --> 00:14:48.360
がシークレットを取得するように 構成できます

00:14:48.360 --> 00:14:52.600
すべてのサービスが同じidシステム 同じrbacロール同じ監査ログ

00:14:52.600 --> 00:14:54.420
を使用して一貫した方法で統合 されます

00:14:54.420 --> 00:14:56.960
ci cdパターンは特に強力です

00:14:56.960 --> 00:14:59.280
パイプラインはデプロイ時に キーファウルトからシークレット

00:14:59.280 --> 00:14:59.860
を取得します

00:14:59.860 --> 00:15:02.360
これらをパイプライン変数や リポジトリのシークレットに保存

00:15:02.360 --> 00:15:03.060
することはありません

00:15:03.060 --> 00:15:05.880
データベースのパスワードをローテーション する必要がある場合はキーファウルト

00:15:05.880 --> 00:15:06.720
で更新するだけです

00:15:06.720 --> 00:15:09.860
次回のパイプライン実行時に 新しい値が自動的に読み込まれます

00:15:09.860 --> 00:15:12.960
パイプラインの変更もコードの変更 も再デプロイも不要です

00:15:12.960 --> 00:15:14.640
ここですべてがうまく噛み合います

00:15:14.640 --> 00:15:18.160
マネージドidとrbacでキーファウルト を設定すれば視覚情報管理について

00:15:18.160 --> 00:15:19.480
考える必要は完全になくなります

00:15:19.480 --> 00:15:21.160
アプリケーションはそのまま機能 します

00:15:21.160 --> 00:15:23.500
シークレットは誰にも気づかれる ことなくローテーションされます

00:15:23.500 --> 00:15:25.800
証明書も真夜中の緊急対応なしで 更新されます

00:15:25.800 --> 00:15:27.720
システムがすべてバックグラウンド で処理します

00:15:27.720 --> 00:15:29.760
これこそが重要なセキュリティ 体制です

00:15:29.760 --> 00:15:32.140
境界となるのはネットワークでは なくidです

00:15:32.140 --> 00:15:35.120
仮想ネットワークの内側にいる か外側にいるかは問題ではありません

00:15:35.120 --> 00:15:38.540
重要なのは適切な権限を持つ 有効なidがあるかどうかです

00:15:38.540 --> 00:15:40.880
キーファウルトは設計上これを 強制します

00:15:40.880 --> 00:15:43.700
すべてのアクセス要求はどこから発信 されたかに関わらず

00:15:43.700 --> 00:15:47.980
entra id認証とrbac認可を通過します そしてすべてがログに記録されます

00:15:47.980 --> 00:15:50.420
シークレットの読み取りキー 操作証明書の取得のすべてです

00:15:50.420 --> 00:15:52.500
誰が何をいつアクセスしたかを 確認できます

00:15:52.500 --> 00:15:55.260
不審な動きがあれば調査のための データが手元にあります

00:15:55.260 --> 00:15:58.420
これはコンプライアンスやインシデント 対応そして環境内で何が起きている

00:15:58.420 --> 00:15:59.580
かを把握するために不可欠です

00:15:59.580 --> 00:16:01.200
それがすべての素晴らしさです

00:16:01.200 --> 00:16:05.760
キーファウルトentra idrbacmanaged id は統合された セキュリティフレームワーク

00:16:05.760 --> 00:16:06.420
として連携します

00:16:06.420 --> 00:16:08.500
それぞれの要素が互いを強化します

00:16:08.500 --> 00:16:12.640
すべてが正しく設定されれば 自分で構築するよりも安全で運用

00:16:12.640 --> 00:16:15.460
もシンプルな資格情報管理システム が手に入ります

00:16:15.460 --> 00:16:16.860
実践的なヒント

00:16:16.860 --> 00:16:19.280
では今すぐ具体的に何をすべき でしょうか

00:16:19.280 --> 00:16:21.000
この知識を行動に移しましょう

00:16:21.000 --> 00:16:23.020
今週取り組めることは以下の 通りです

00:16:23.020 --> 00:16:24.760
まずは権限モデルから始めましょう

00:16:24.760 --> 00:16:27.780
ポータルでキーファウルトを開き アクセス構成を確認してください

00:16:27.780 --> 00:16:30.620
ファウルトアクセスポリシーと表示 されていればそれは古い方法です

00:16:30.620 --> 00:16:33.780
代わりにAzureロールベースのアクセス 制御RBACを使用する必要があります

00:16:33.780 --> 00:16:35.060
移行は簡単です

00:16:35.060 --> 00:16:37.820
権限モデルを切り替え既存の アクセスポリシーを持っていた

00:16:37.820 --> 00:16:39.680
ユーザーにRBACロールを割り当て ます

00:16:39.680 --> 00:16:41.120
今日中に実行しましょう

00:16:41.120 --> 00:16:44.120
これはマイクロソフトが推奨する 手法であり前述の調査結果が

00:16:44.120 --> 00:16:45.080
その理由を裏付けています

00:16:45.080 --> 00:16:48.120
次にキーファウルト貢献者ロール を持つアカウントを監査します

00:16:48.120 --> 00:16:50.840
ファウルトのアイアムブレードを開き 誰が貢献者アクセス権を持っている

00:16:50.840 --> 00:16:51.520
かを確認してください

00:16:51.520 --> 00:16:53.840
そのロールを持つ全員には妥当な 理由が必要です

00:16:53.840 --> 00:16:55.340
ほとんどの場合そうではありません

00:16:55.340 --> 00:16:58.300
共同作成者コントリビュータは より具体的な権限に置き換えましょう

00:16:58.300 --> 00:17:00.660
シークレットの読み取りのみが必要な 場合はキーファウルトシークレット

00:17:00.660 --> 00:17:01.340
ユーザーを割り当てます

00:17:01.340 --> 00:17:03.960
管理が必要な場合はキーファウルト シークレットオフィサーを使用

00:17:03.960 --> 00:17:04.300
してください

00:17:04.300 --> 00:17:07.100
目標はその特権昇格の経路を完全に 塞ぐことです

00:17:07.100 --> 00:17:09.360
次にマネージドIDを活用しましょう

00:17:09.360 --> 00:17:11.800
キーファウルトへのアクセスが 必要な全てのアジュールサービス

00:17:11.800 --> 00:17:12.680
でこれを使うべきです

00:17:12.680 --> 00:17:15.580
ウェブアプリファンクションデータ ファクトリーあるいは仮想マシン

00:17:15.580 --> 00:17:18.180
で依然としてクライアントシークレット 付きのサービスプリンシパル

00:17:18.180 --> 00:17:20.320
を使っているならマネージドIDに 切り替えてください

00:17:20.320 --> 00:17:23.840
その方がシンプルで安全ですし先ほど 取り上げた鶏と卵の問題も

00:17:23.840 --> 00:17:24.380
解決します

00:17:24.380 --> 00:17:27.420
アジュールが裏側で認証情報の 管理を自動的に処理してくれます

00:17:27.420 --> 00:17:30.720
もう一つ全てのファウルトで 論理的な削除と消去保護を有効

00:17:30.720 --> 00:17:31.140
にしてください

00:17:31.140 --> 00:17:34.160
論理的な削除は新しいファウルト ではデフォルトで有効ですが消去

00:17:34.160 --> 00:17:34.780
保護は違います

00:17:34.780 --> 00:17:36.100
必ずオンにしましょう

00:17:36.100 --> 00:17:39.100
その設定により保持期間中に ファウルトやその中身を誰かが

00:17:39.100 --> 00:17:40.420
完全に削除するのを防げます

00:17:40.420 --> 00:17:43.280
これまで多くのチームが致命的な ミスから救われてきました

00:17:43.280 --> 00:17:44.840
ここからがアクションプランです

00:17:44.840 --> 00:17:47.040
現在のシークレット管理方法を 見直してください

00:17:47.040 --> 00:17:49.720
構成ファイルや環境変数の中に残っている かコードに直処されている

00:17:49.720 --> 00:17:50.700
シークレットを一つ見つけましょう

00:17:50.700 --> 00:17:52.460
今週中にそれをキーハウルトへ 移行してください

00:17:52.460 --> 00:17:53.540
たった一つでいいのです

00:17:53.540 --> 00:17:55.880
どれほど簡単か分かれば残りの シークレットも全て移したくなる

00:17:55.880 --> 00:17:56.200
はずです

00:17:56.200 --> 00:17:57.800
セキュリティは一度設定して終わり ではありません

00:17:57.800 --> 00:17:58.940
継続的な習慣です

00:17:58.940 --> 00:18:01.220
キーハウルトはその実践を容易に しますがそれは正しく使用した

00:18:01.220 --> 00:18:01.780
場合に限ります

00:18:01.780 --> 00:18:02.840
ツールは揃っています

00:18:02.840 --> 00:18:04.240
パターンは実証済みです

00:18:04.240 --> 00:18:06.140
あとはあなたがそれを実装する だけです

00:18:06.140 --> 00:18:07.580
システムとはそういうものです

00:18:07.580 --> 00:18:10.220
キーハウルトはデジタル金庫 ですがその安全性は周囲に施す

00:18:10.220 --> 00:18:11.060
アクセス制御次第です

00:18:11.060 --> 00:18:13.080
まずは私が説明した監査から 始めましょう

00:18:13.080 --> 00:18:14.560
権限モデルを確認してください

00:18:14.560 --> 00:18:17.140
共同作成者の割当てをチェック し今週中に一つのシークレット

00:18:17.140 --> 00:18:17.980
をファウルトへ移行しましょう

00:18:17.980 --> 00:18:20.200
今後も分かりやすいクラウド セキュリティのヒントを得るために

00:18:20.200 --> 00:18:22.920
登録を設定ファイルにシークレット を保存している知人にもぜひ

00:18:22.920 --> 00:18:23.900
この動画を共有してください