こんにちは！インフラや開発の現場に飛び込んだばかりの頃は、覚えることが山積みで大変ですよね。「クラウドへの移行」なんて聞くだけで、なんだか難しそうな要塞を築くようなプレッシャーを感じてしまうかもしれません。
でも、安心してください。セキュリティの基本は、私たちが普段暮らしている現実世界の「防犯」とまったく同じなんです。
今回は、会社の大切なシステムやデータを守るための「クラウド移行時の鍵の管理（IAM：Identity and Access Management）」について、身近な例えを交えながら一歩ずつ優しく紐解いていきたいと思います。一緒に楽しく学んでいきましょう！
—
1. なぜクラウド移行で「鍵」の管理が難しくなるの？
これまで会社で使っていた古いシステム（レガシーなディレクトリサービス）は、いわば「社屋ビルの中にある頑丈な金庫室」のようなものでした。会社の中にいれば安全で、合鍵の管理も総務部が目の届く範囲でやってくれていましたよね。
しかし、これをクラウド（AWSやAzure、GCPなど）へ移行するというのは、「オフィスを世界中に支店があるオープンな巨大プラザに引っ越し、社員証一枚でどこからでも出入りできるようにする」ようなものです。
ここでよくある失敗が、「引っ越し作業が面倒だから」という理由で、とりあえず全員に「マスターキー（管理者権限）」を配ってしまうことです。
泥棒（攻撃者）が狙う「過剰な権限」の盲点
もし、新人のアルバイトスタッフのロッカーの鍵に、うっかり「オフィスの金庫の鍵」が混ざっていたらどうなるでしょうか？
もしそのスタッフが外でうっかりカバンを盗まれてしまったら、泥棒は労せずして金庫の現金をごっそり持ち出すことができますよね。
サイバー攻撃の世界でもまったく同じことが起きています。攻撃者は、セキュリティ対策が甘い一般社員のパソコンや、権限が強すぎるテスト用のアカウントを狙って侵入します。
もしそのアカウントに「何でもできる権限（過剰な権限）」が与えられていたら、攻撃者は一瞬でシステム全体の「マスター」になり、すべてのデータを人質に取ったり、勝手に改ざんしたりできてしまうのです。
だからこそ、クラウド移行のタイミングで絶対に守らなければならないのが、「最小権限の原則（The Principle of Least Privilege）」になります。
—
2. 最小権限の原則ってなに？（家の鍵で例えてみよう）
「最小権限の原則」なんて言うと、なんだか堅苦しい呪文のようですが、考え方はとてもシンプルです。
想像してみてください。あなたは一戸建ての家を建てました。
- あなた（オーナー）：すべての部屋に入れます（マスターキー）
- 家族：リビングや自分たちの部屋には入れますが、屋根裏や床下の金庫室には入れません
- 郵便配達員（外部サービス）：玄関の郵便受けに手紙を入れることしかできません。家の中には一歩も入れません
これが「最小権限の原則」です。「その人が仕事をするために必要最低限の場所（リソース）にしか、アクセスできる鍵を渡さない」という、防犯の基本中の基本なんですよ。
クラウドのIAM（アイデンティティ管理）でも、これと同じ設計をしていきます。
—
3. 実践！クラウドIAMでの「最小権限」の設計と設定
それでは、実際にクラウド（今回は代表的な例としてJSON形式のポリシーを用いる環境を想定します）で、どのように権限を絞っていくのかを見てみましょう。
例えば、「開発チームのメンバーに、ログの確認（読み取り）だけを許可し、サーバーを勝手に消したり作ったりする権限は絶対に与えたくない」という場合の設定例です。
よくない設定（やってはいけない例）
とりあえず動けばいいやと、すべてを許可してしまう（* は「すべて」の意味です）最悪のパターンです。これでは家の鍵を開けっ放しにしているようなものです。
{
"Version": "2012-10-17",
"Statement": [
{
"Effect": "Allow",
"Action": "*",
"Resource": "*"
}
]
}良い設定（最小権限を適用した例）
必要な人には、必要な場所の、必要な操作（この場合はログを読むこと）だけを許可するように、しっかりとお行儀よく制限します。
{
"Version": "2012-10-17",
"Statement": [
{
"Sid": "AllowReadAccessOnlyToLogs",
"Effect": "Allow",
"Action": [
"logs:DescribeLogStreams",
"logs:GetLogEvents"
],
"Resource": "arn:aws:logs:ap-northeast-1:123456789012:log-group:my-app-logs:*"
}
]
}【ここに注目！設定のポイント】
Effect: 「許可する（Allow）」または「拒否する（Deny）」を指定します。Action: 「何ができるか」を細かく指定しています。今回はログの読み取りに必要な操作だけに絞っています。Resource: 「どこに対して行うか」を特定のロググループに限定しています。これにより、他の大事なデータファイルには一切触れられなくなります。
このように、コードや設定ファイルを書きながら「本当にこの操作は必要かな？」「他のデータが見えてしまわないかな？」と一つひとつ確認していくことが、セキュアなインフラを作る第一歩になります。
—
4. 移行期にやりがちな落とし穴と監査のコツ
レガシーなシステムからクラウドへ移行する際、現場ではどうしても「早くシステムを動かしたい！」というプレッシャーから、権限がゆるゆるになりがちです。
現場のエンジニアとしてお伝えしたい、リアルな落とし穴と対策をいくつか挙げておきますね。
1. 「一時的」のつもりがそのまま放置される管理者権限
- *対策*：移行作業のために一時的に強い権限を付与した場合は、カレンダーにリマインダーを設定し、作業が終わったら即座に権限を剥奪するルールを徹底しましょう。
2. 退職者や異動した人のアカウントがそのまま残っている
- *対策*：クラウドIAMと会社のID管理システム（Azure AD / Oktaなど）をしっかり連携させ、人が動いたら自動的に鍵が無効化される仕組みを作りましょう。
3. 定期的な「鍵の棚卸し（監査）」をしていない
- *対策*：月に一度など、定期的に「このアカウントは本当にまだこの権限が必要か？」をチーム全員でチェックする時間を設けるだけでも、セキュリティ事故のリスクは劇的に下がります。
—
5. おわりに：セキュリティは「思いやり」
いかがでしたでしょうか？
クラウドのIAMや最小権限の原則聞くと難しく感じるかもしれませんが、要は「自分たちのシステムという大きなお家を、泥棒から守るための賢い施錠術」にすぎません。
セキュリティの対策を丁寧に行うことは、会社の大切な資産を守るだけでなく、一緒に働く仲間やユーザー、そして自分自身をも守ることに繋がります。「使いやすさ」と「安全な鍵の管理」のバランスを取りながら、一歩ずつ着実にスキルアップしていきましょう！
これからも分からないことがあれば、いつでも周りの先輩やこういった解説を頼ってくださいね。応援しています！
コメント