メインコンテンツへスキップ

認証・認可とID管理(IAM)の基本

    セキュリティ対策の1丁目1番地「IAM(Identity and Access Management)」
    日本語では「認証・認可を含むID管理」と表現されることもあります。
    IAMの本質は、「あなたは誰? あなたは、本当にあなたなの?」を問うことです。
    僕が僕であることを、証明しなければなりません。
    そして証明できて初めて「何をしてよいか」が決まります。
    IAMについて、①防御 → ②検知 → ③対応 → ④復旧という軸で考えてみたいと思います。


    ①IAMにおける防御

    まず、個人を特定するためにはIDを払い出す必要があります。
    クラウドサービスではメールアドレスが利用されることが多いため、本記事ではメールアドレスを例に説明します。
    メールアドレスには、個を表す@よりも前の部分(ローカル部)と、所属を表す@よりも後の部分(ドメイン)があります。

    seiji_kondo@hogehoge.co.jp
    ⇒ seiji_kondo は hogehoge.co.jp という組織に所属しているよ。

    その人のIDを払い出したら、パスワードやMFAなどの認証方式を設定し、以下のような対策で「なりすまし」に対する防御を行います。

    • パスワード

    • 多要素認証(MFA)

    • パスワードレス認証(パスキーなど)

    • 生体認証(指紋・顔認証)

    • リスクベース認証(いつもと異なる場合に再認証を求める)

    • 条件付きアクセス

    これによって、パスワード漏洩やリスト攻撃、フィッシングやアカウント乗っ取りに対抗します。
    あわせて使わなくなったIDを早めに削除することも大切です。
    利用者のいないIDは、乗っ取られても気づく人がいないので、絶好の攻撃対象になります。

    本人確認できたから何でもOKというわけではありません。
    次に役割、属性、職務分掌などを元に、必要最小限の権限を付与する必要があります。
    これを認可(Authorization)と言います。
    認可をしっかりやることで、以下のような効果があります。

    • 内部不正防止

    • 誤操作抑止

    • 情報漏えい抑止

    特にシステムの管理者権限は一般利用者よりも守るべき領域です。
    ここは個別に運用設計を実施する箇所でもあります。
    特権IDは分離して、出来ればJust-In-Time(必要な時だけ付与)、付与には承認プロセスを踏み、セッション記録とログの監視を行います。
    ここまで実施することで、管理者アカウントの乗っ取りリスクを低減するとともに、不正利用が発生した場合でも早期に発見できるようになります。


    ②IAMにおける検知

    まずは防御の対策をしっかりやるのが前提ですが、敵はさるものAIだものなので、何かの穴をついてくる可能性があります。
    そもそも、人間による設定ミスや未知の脆弱性などもあります。
    そのためには、監視でいろいろな違和感を拾う必要が出てきます。

    • 普段利用しない国・地域からのログイン

    • 深夜や休日のログイン

    • 短時間で複数拠点からのログイン

    • 異常な回数のログイン失敗

    「東京でログインした10分後にアメリカからログイン」なんてことがあったら、めっちゃ怪しいです。
    また、最近ではUEBA(User and Entity Behavior Analytics)によって、利用者の通常行動から逸脱したアクセスを検知する仕組みも普及しています。

    他にも、認証を突破された可能性というのも考えます。

    • MFA登録情報の変更

    • パスワード変更直後の異常行動

    • ログイン方法の変更

    • 新しいデバイスからのアクセス

    攻撃者は侵害したアカウントへのアクセスを継続したいため、MFA情報や認証方法の変更を試みることがあります。
    特に危ないのは、管理者権限などの特権アカウントの乗っ取りです。

    • 一般利用者への管理者権限付与

    • 予定にない特権ロールへの追加、グループメンバー変更

    • 大量の権限変更

    これを検知するためには、承認プロセスで作業を可視化した上で、「誰が誰に権限を付与しているのか」を監視する必要があります。


    ③IAMにおける対応

    アカウント侵害を検知したら、出来るだけ素早く以下を行います。

    1. アカウントの隔離・無効化

    2. セッションの強制終了(既にログインされている場合)

    3. パスワードリセット

    4. 権限剥奪

    5. 条件付きアクセスの強化

    6. インシデント調査

    このあたりはセキュリティインシデント対応手順として整理しておきたいところですが、1~5までは訓練して誰でも対応できるようにしておきたいところです。
    調査のフェーズでは、誰のアカウントでいつ侵害されたか、どのシステムにアクセスして何のデータを参照したか、権限は変更されたか等を調べることになります。


    ④IAMにおける復旧

    IAMにおける復旧は、被害を止めた後に利用者が安全に業務へ戻れる状態にすることです。
    安全が確保されたことを確認し、本人確認や、場合によっては事情聴取などを行った上で、アカウントを再有効化します。
    そのあと、パスワードやMFAなどの再設定をしたり、必要に応じて権限をみなおしたりして業務を再開してもらいます。

    そして、最も大切なことは再発防止です。
    特にIAMはユーザーがフィッシングメールなどに引っかかってしまうということも多いので、セキュリティ教育を継続して実施することも防御として必要になります。
    復旧は「元に戻すこと」ではありません。
    原因を分析し、設定・運用・教育を改善して、以前よりも安全な状態にすることが本当の復旧です。



     
     
    運用設計エンジニア、運用コンサルティングなどをやっています。趣味は小説書き。第47回埼玉文学賞正賞受賞。

    あなたへのおすすめ