こんにちは！インフラやクラウドの世界へようこそ。
システム開発やインフラの構築をしていると、「サーバーの初期設定」や「アカウントの管理」など、覚えることが山ほどあって大変ですよね。
今回は、セキュリティのプロである私たちが現場で一番大切にしている、「IAMにおける最小権限の原則（PoLP：Principle of Least Privilege）」と、その具体的な守り方についてお話ししていきます。
難しそうに聞こえる名前ですが、考え方はとってもシンプル。一歩ずつ、身近な例えから紐解いていきましょう！
—
1. 家の鍵に例えて考える「最小権限の原則」
突然ですが、みなさんのご自宅の「鍵」を思い浮かべてみてください。
家族全員が住んでいる玄関の鍵は、全員が持っていますよね。では、家のなかの「金庫の鍵」や「薬箱の鍵」はどうでしょうか？
家族全員に、いつでもどこでも金庫を開けられるマスターキーを持たせたりはしないはずです。家族であっても、「必要な人だけが、必要な時だけ開けられる」ように管理しているのではないでしょうか。
もし家族全員がマスターキーを持っていたらどうなるでしょう？
万が一、ひとりの子供がお友達を家に呼んだときにおもちゃ感覚で金庫を開けてしまったり、財布からお金を持ち出したりしても気づきにくくなります。
サーバーやクラウド（AWSやAzureなど）の世界でも、これと全く同じことが言えます。
アプリケーションや開発者（ユーザー）に、すべての権限（マスターキー）を最初から渡してしまうのは、「家のなかのすべての場所に誰でも入れるマスターキーを配り歩いている」ようなものなんです。
これが、サイバー攻撃者に狙われる最大の盲点になります。
—
2. なぜ「最小権限」がないと危険なのか？（攻撃のメカニズム）
もし、あるWebアプリケーションが動くためのサーバーアカウントに、「データベースの全削除もできるし、すべてのクラウド設定も変更できる（管理者権限）」という強い権限が与えられていたとします。
ある日、そのWebアプリケーションに「脆弱性（プログラムのちょっとした隙やバグ）」が見つかり、悪意あるハッカーに侵入されてしまったとしましょう。
ハッカーは、そのアプリケーションが持っている権限をそのまま乗っ取ります。
もし権限が「必要最低限（データベースの特定のテーブルを読むだけ）」であれば、被害はそこで食い止められます。
しかし、そこに「管理者権限」というマスターキーがあったとしたらどうでしょう？
ハッカーは一瞬でシステム全体の主導権を握り、データをすべて人質に取って身代金を要求したり、サーバーを完全に破壊したり、他の顧客データをごっそり盗み出したりできてしまいます。
「最小権限の原則（PoLP）」とは、「たとえどこか一つの扉（アプリ）が破られても、家全体の金庫までは開けられないようにバリケードを作っておく」という、極めて現実的で強力な防衛策なのです。
—
3. IAM（Identity and Access Management）でできること
クラウドやサーバーOSの世界では、誰が・何に・どこまでアクセスできるかを管理する仕組みを IAM（アイアム） と呼びます。
このIAMを使うことで、「〇〇のアプリは、△△のフォルダだけ見ていいけれど、書き込みはしちゃダメ」といった細かいルール（ポリシー）を作ることができます。
さらに、現代のクラウドセキュリティでは、単に「誰がアクセスするか」だけでなく、「どんな条件のときにアクセスを許可するか（Condition）」という文脈を持たせることが主流になっています。
—
4. 実践！IAMポリシーの条件句（Condition）を使ったアクセス制限
百聞は一見に如かず。実際にクラウド（例：AWSのIAMポリシー）で、どのように最小限の権限と条件を設定するのかを見てみましょう。
以下の設定例は、「特定の社内ネットワーク（IPアドレス）からのみ、ストレージ（S3バケット）へのアクセスを許可する」というポリシーのサンプルです。
{
"Version": "2012-10-17",
"Statement": [
{
"Sid": "AllowOnlyFromCompanyNetwork",
"Effect": "Allow",
"Principal": "*",
"Action": "s3:GetObject",
"Resource": "arn:aws:s3:::our-company-secure-bucket/*",
"Condition": {
"IpAddress": {
"aws:SourceIp": "203.0.113.50/32"
}
}
}
]
}丁寧なコード解説
Effect: "Allow": 許可を表します。Action: "s3:GetObject": 「ファイルを読み取る（ダウンロードする）権限」だけに絞っています。ファイルを消したり作ったりする権限は与えていません（これが最小権限の考え方です）。Condition（ここがポイント！）: 「どの条件のときに許可するか」を定めています。ここではIpAddressを使って、会社の公式ルーターのIPアドレス (203.0.113.50) からのアクセス以外は、たとえ正しいパスワードを持っていても一切通さないように制限しています。
これなら、万が一パスワードが外に漏れてしまっても、ハッカーが自宅のパソコンからアクセスしようとした瞬間に、クラウド側で自動的にシャットアウトされますよね。
—
5. 現場のエンジニアとして伝えたいこと
新人の頃や、開発を急いでいるときは、「めんどくさいから、とりあえず全部の権限（フルアクセス）を与えておこう」となりがちです。現場でもよく見かける誘惑です。動かない原因を探すよりも、すべてを許可した方が手っ取り早く動くように見えるからです。
しかし、その「とりあえず」の油断が、のちに重大なインシデント（情報漏洩やシステム停止）を引き起こす引き金になります。
セキュリティ対策は、一度に完璧を目指す必要はありません。
「このユーザーには、このファイルを読む権限だけで十分かな？」
「このサービスアカウントは、夜間のバッチ処理中だけ動けばいいから、昼間は止めておこうかな？」
そんなふうに、身の回りの鍵をかけるような優しさと慎重さを持って、一つひとつの権限を見直していくこと。それが、あなた自身と、あなたが作るシステムを守る最強の盾になります。
一歩ずつ、安全で堅牢なインフラストラクチャを作っていきましょう！応援しています。
コメント