【入門編】マネージドIDを用いたクラウドサービス間認証のセキュアな実装 – インフラ・ネットワーク & クラウドセキュリティ防御ガイド

こんにちは！インフラやセキュリティの世界へようこそ。
クラウドサービスを使ったシステム開発、便利でワクワクしますよね。「サーバーを何台も立てなくても、ボタン一つでデータベースやストレージが使える！」という感動を味わっている方も多いのではないでしょうか。

さて、そんな便利なクラウドですが、一つだけ大きな悩みがあります。それが「サービスとサービスをつなぐときの認証（合言葉）」の問題です。

例えば、Webサーバーからデータベースにアクセスする時や、ストレージにファイルを保存する時、「このサーバーはアクセスしてもいいですよ」と証明するために、これまで私たちはどうしていたでしょうか？
プログラムの中にパスワードを直接書いたり、秘密の鍵ファイルをサーバーの中にこっそり保存したりしていましたよね。

実はここ、攻撃者が一番狙っている「一番危うい盲点」なんです。

今回は、そんなパスワード管理の苦しみから私たちを解放してくれる、次世代のセキュリティ技術「マネージドID」について、身近な例えを交えながら優しく紐解いていきたいと思います。一歩ずつ、一緒に学んでいきましょう！

—

1. なぜ「パスワードのハードコード」は泥棒を招くのか？

まずは、これまでのやり方の何が危ないのかを、私たちの身近な「家と鍵」の例えで考えてみましょう。

あなたが新しくお店を開いたとします。毎朝、従業員にシャッターを開けてもらうために、全員に「合言葉（パスワード）」を共有しました。さらに、裏口の鍵（秘密鍵ファイル）も、念のためそのへんの引き出しに入れておきました。

これ、すごく危なっかしいですよね？

バイトの従業員が辞めるときに、合言葉をメモして持ち出してしまうかもしれない。
ちょっとした油断で、引き出しの鍵が盗まれてしまうかもしれない。
万が一、お店のパソコンがウイルスに感染して中身を覗かれたら、すべての合言葉が敵に丸見えになってしまう。

プログラムの世界でもまったく同じことが起きています。
ソースコードの中にデータベースのパスワードをそのまま書くこと（ハードコードと言います）や、サーバーのフォルダにアクセスキーのファイルを置きっぱなしにすることは、「裏口の鍵をドアの隙間に挟んで出かけるようなもの」なんです。

実際に、GitHub（プログラムを共有するサイト）にうっかりパスワードを載せたまま公開してしまい、数分後には世界中のボット（自動プログラム）に悪用されて、勝手に高額なクラウドサーバーを立てられて仮想通貨を採掘されてしまった……なんて事故は、現場で毎日のように起きています。笑い事ではなく、本当に怖い話ですよね。

—

2. マネージドIDとは？ —— 「身分証明書付きの社員証」の仕組み

じゃあ、どうすればいいのでしょうか？パスワードを覚えるのも管理するのもやめにして、もっと安全な方法を使いましょう。それが「マネージドID（Managed Identity）」です。

またまた身近な例えに戻りましょう。
先ほどのお店の例で、「合言葉を教え合う」のをやめました。代わりに、お店のオーナー（クラウド事業者、例えばAzureやAWS、GCP）が発行した、「絶対に偽造できない、その人の顔写真と所属がピカッと光る電子社員証」を従業員に持たせることにしました。

従業員がバックヤード（データベース）に入ろうとすると、自動ドアのセンサーがその「電子社員証」をピッと読み取ります。
「お、君はうちのスタッフの〇〇さんだね。顔写真もデータも本物だ。入れよう！」
こうして、パスワードを一切口にすることなく、安全に中に入ることができるようになります。しかも、この社員証はクラウド側が勝手に発行・管理（マネージ）してくれて、従業員が勝手にコピーすることもできません。これが「マネージドID」の正体です。

クラウド上で動くサーバー（仮想マシンやコンテナなど）自体に、この「電子社員証」を持たせてあげることで、データベースやストレージなどの他のサービスとパスワードなしで安全に会話ができるようになるんです。

—

3. 実践！クラウドサービス間でのセキュアな実装例

「理屈は分かったけれど、実際にどうやってコードを書くの？」
安心してください。ここからは、実務でそのまま使える設定とコードのイメージを見ていきましょう。

今回は例として、Pythonを使ってクラウド上のストレージにファイルを保存する処理を考えてみます。昔のやり方と、マネージドIDを使った今のやり方を比べてみましょう。

昔のやり方（危険なパスワード管理）

プログラムの中に、長くて危うい接続文字列をそのまま書いてしまっています。

# 【危ない例】ソースコードにパスワード（接続文字列）が丸見え！
# もしこのコードがGitHubに漏れたら、一瞬でストレージが乗っ取られます。
connection_string = (
    "DefaultEndpointsProtocol=https;"
    "AccountName=mykaishastorage;"
    "AccountKey=super_secret_password_12345_abcdefg...;"  # <- ここが狙われる！
    "EndpointSuffix=core.windows.net"
)

# ストレージに接続する
# blob_service_client = BlobServiceClient.from_connection_string(
#     connection_string
# )

今のやり方（マネージドIDを使った安全な実装）

パスワードの代わりに、クラウドが用意してくれた「身分証明書（DefaultAzureCredentialなど）」をただ呼び出すだけです。パスワードの「パ」の字も出てきません！

# 【安全な例】マネージドIDを使ったセキュアな実装
from azure.identity import DefaultAzureCredential
from azure.storage.blob import BlobServiceClient

# 1. クラウド基盤が自動管理する「身分証明書」を取得する
# コード内にはパスワードも秘密鍵も一切書きません。
credential = DefaultAzureCredential()

# 2. ストレージのアドレスだけを指定して接続する
# 身分証明書はクラウドが裏側で勝手に提示してくれます。
storage_account_url = "https://mykaishastorage.blob.core.windows.net"
blob_service_client = BlobServiceClient(
    account_url=storage_account_url, credential=credential
)

# これで安全にストレージ操作ができます！
print("マネージドIDを使って安全に接続できました！")

このように、コードから秘密の情報を完全に排除することが、インフラの要塞化（ハーデニング）において最も強力な武器になります。

—

4. 現場のセキュリティ担当からあなたへ：一歩ずつ進むために

さて、ここまでマネージドIDの仕組みと素晴らしさをお話ししてきました。
「なんだか難しそうだな……」と思った方もいるかもしれませんが、安心してください。セキュリティのプロである私たちも、最初からすべてを完璧にできていたわけではありません。

現場で意識してほしいのは、たった一つのシンプルなルールです。

「ソースコードや設定ファイルの中に、パスワードや鍵を絶対に書かない・置かない」

まずはこの意識を持つだけで、あなたの作るシステムは、世の中の大半の脆弱なシステムよりもぐっと安全になります。クラウドを使うときは、「あ、ここにパスワードを直書きしちゃいけないんだな、マネージドIDが使えないかな？」と、一歩立ち止まって考える癖をつけてみてください。

失敗を恐れず、少しずつセキュアな開発・インフラ構築のスキルを身につけていきましょう。あなたのエンジニアライフを、心から応援しています！