「ID」が守りの要 ―"アクセス権限のダイエット"から始める年始・年度はじめ
新しい年や年度の始まり、このようなタイミングでぜひ見直しておきたいのがセキュリティの設定。
「侵入は"ログイン"から始まる」ため、攻撃者は複雑な技術で壁を越えるより、社員になりすましてログインする方が早い時代になりました。メールのだましや電話のなりすまし、偽の画面でワンタイムコードを盗む手口など、"人の判断"を揺さぶる攻撃が増えています。
だからこそ、本人確認（ID）を強くすることと、権限（できることの範囲）を必要最小限に絞ることが、最も効果的な守りになります。
なぜ「ID」が戦場なのか
最近の事例では、「MFA疲労攻撃」や中間者（偽サイト・偽Wi-Fi）攻撃、セッション奪取など「認証まわり」を突かれて"ログイン"を奪われる傾向が明確です。さらにAIによるなりすまし音声や高度なフィッシングで、従来の「パスワード＋ワンタイムコード」だけでは守り切れない場面が増えています。
これからは、行動・コンテキスト・端末健全性・継続的な再確認も含めて守るのが標準です。
まずは全社員が行う"今日の3つ"
はじめにまず身近に社員が行うべき行動を徹底する必要があります。
- MFA（多要素認証）を必ずON
社内アカウントでMFAをまだ設定していない人は、今日中に設定する。スマホ認証アプリかセキュリティキー（FIDO2/YubiKeyなど）の利用を推奨します。
＜補足＞
MFAの押しすぎ対策
通知が多すぎる・身に覚えのない承認要求が来たら承認しないでください。セキュリティキーは誤承認リスクを低減できます。
- パスワード再利用の禁止
他サービスと同じパスワードはNG。必ず長く・ユニークなパスワードを使います。パスワード管理ツールの利用も効果的です。
- "怪しい画面"ではコードを入れない
「ログインが切れました」「確認コードを入力してください」などの急かす表示は要注意です。必ずURLが正しいかを確認してください。
管理者が行う"権限のダイエット"4か条
次に、チームリーダーや管理者が行う、権限の見直し「権限のダイエット」のポイントをご紹介します。
- 最小権限
必要な作業だけができる権限に絞ります（余分は削る）。
- 期限付き昇格（JIT, ジャストインタイム）
一時的に管理者権限を付与し、作業が終わったら自動で戻します。
- 共有アカウント廃止
誰が使ったか分からないアカウントは事故のもとです。個人ID＋承認フローに切り替えます。
- 鍵・トークンの短寿命化
長期のAPIキーや使い回しトークンはやめて、短時間の発行（使い捨て）にします。
＜補足＞
"設定値の初期値のまま"対策
AWSを含む各クラウドは柔軟ですが、既定値が安全とは限りません。社内テンプレートの安全な初期設定（ネットワーク制限／MFA必須／HTTPS必須など）を適用してから運用を開始することが大切です。
AWSでの設定例
次に、ここまで見てきた「権限のダイエット」をAmazon Web Services (AWS)環境で実施する場合の具体的な設定内容について見ていきます。
設定の概要
以下の設定をAWSで簡単に実現します。
- 「管理者操作はMFA必須＋社内からのみ」
- 「管理者は必要時のみ一時付与
- 「古いアクセスキーを排除」
(1)管理者ロールはMFAが有効な人だけが使えるようにする
- 行うこと
管理者ロール（例：AdminRole）の信頼ポリシーに「MFAが有効なときだけAssumeRoleできる」条件を入れます。
- ポイント
ウイルスでも人でも、「MFAなしでは管理者になれない」状態にします。 - 運用のコツ
IAM Identity Center（旧AWS SSO）を使っている場合も、IdP側でMFA必須にし、管理者用のPermission Setはセッション1時間など短めに設定します。
MFA を使用した安全な API アクセス - AWS Identity and Access ManagementMFA を使用した安全な API アクセス - AWS Identity and Access Management
ユーザーが AWS サービスをプログラムから呼び出す前に MFA を使用して認証するように、IAM を設定します。
https://docs.aws.amazon.com/ja_jp/IAM/latest/UserGuide/id_credentials_mfa_configure-api-require.html
(2)場所の制限をかける（社内ネットワークからのみ管理者操作）
- 行うこと
管理者ロールのアイデンティティベースポリシーで、Denyを条件ごとに分けて記述します。- 社内IPレンジ以外はDeny
- MFAが有効でない操作はDeny
- HTTPS（aws:SecureTransport）でない通信はDeny
- 効果
いずれかの条件を満たしていない操作を確実に拒否でき、設定の抜けによる誤許可を防げます。
- 補足
IAM Identity Center利用時も、IdP側でMFA必須にして整合を取りましょう。既存の許可ポリシーにAllowがあっても、設定したDenyが優先されます。
- 運用のポイント
APIや管理コンソールの利用がプロキシ／VPN経由の場合は、出口IPも許可対象に含めます。設定の変更時は申請・記録のうえ、社内テンプレートへ反映してください。
ポリシーを使用して AWS リソースへのアクセスを制御します。 - AWS Identity and Access Managementポリシーを使用して AWS リソースへのアクセスを制御します。 - AWS Identity and Access Management
(3)期限付き昇格（JIT）で「必要なときだけ管理者」
- 行うこと
普段は一般ロールのみ。申請→承認で管理者ロールを1時間だけ付与する運用に。
- 方法例
- Identity CenterのPermission SetでSession Duration＝1hに設定。
- 承認済み申請からのみ管理者ロールに切り替え可能（社内ツールと連携）。
- メリット
事故の爆発半径が小さくなります／操作の監査履歴が明確になります。
(4)古いアクセスキーの一掃（90日以上は原則廃止）
- 行うこと
IAMのCredential Reportを出し、90日超のアクセスキーをリスト化→削除／再発行。
- 運用ルール
- サーバやCIからAWSを呼ぶときは長期キーではなくロール（AssumeRole）に統一。
- Secrets ManagerでAPIキーを自動ローテーション（可能なもの）に。
AWS アカウント の認証情報レポートを生成します。 - AWS Identity and Access ManagementAWS アカウント の認証情報レポートを生成します。 - AWS Identity and Access Management
(5)"最小権限"のテンプレを使う
- 行うこと
S3なら「読み取りだけ」、Lambdaなら「実行だけ」といった用途別の最小権限ポリシーを社内で用意し、管理者がテンプレから選ぶだけにします。
- 効果
配布ミスや「とりあえずフル権限」の事故を防げます。
まとめ
