【実務・中級編】特権ID管理(PIM)を用いたJust-In-Time(JIT)アクセス権限の付与 – インフラ・ネットワーク & クラウドセキュリティ防御ガイド

「常時フル権限」は死へのパスポート：JITアクセスでインフラの脆弱性を封じ込めろ

現場でインフラを触っていると、「運用が面倒だから」「トラブル時にすぐ入れるように」という理由で、サーバーの root 権限やクラウドの Administrator 権限を、開発メンバー全員に常時付与しているケースによく出くわす。

はっきり言おう。その設定は、攻撃者にとっての「ゴール」を最初から用意しているのと同じだ。

万が一、開発者のPCがマルウェアに感染したり、SSH鍵が漏洩したりした瞬間、その権限は攻撃者の手に渡る。一度侵入した攻撃者は、その常時付与された権限を悪用し、横展開（Lateral Movement）を行い、バックアップを破壊し、データを暗号化する。これがランサムウェアの定石だ。

今回は、この「常時権限」という甘美な毒を捨て、必要な時だけ鍵を開ける「Just-In-Time (JIT) アクセス」による要塞化の極意を伝授する。

—

1. 攻撃者が狙う「常時特権」という盲点

攻撃者が侵入した際、最初に行うのは whoami や sudo -l だ。ここで「自分には無制限の権限がある」と分かった瞬間、彼らは攻撃のアクセルを全開にする。

逆に、JITアクセスが徹底されている環境では、侵入したところで「一般ユーザー」としての権限しかなく、昇格しようとすれば「管理者の承認」という高い壁に阻まれる。この「承認プロセス」が、攻撃者が最も嫌う「時間稼ぎ」と「異常検知」のトリガーになるのだ。

2. 実践：AWS IAMを用いたJIT昇格の仕組み

クラウドインフラにおいて、JITを実現する最も手堅い方法は、「普段は権限のないロールで動かし、必要な時だけ一時的な権限を付与（AssumeRole）する」ことだ。

AWSであれば、AWS IAM Identity Center (旧SSO) と連携し、開発者には「昇格申請フロー」を通さない限り、本番環境への書き込み権限を与えない設計にする。以下は、昇格をリクエストする際のPythonスクリプトの概念例だ。

PythonによるJIT昇格リクエストのイメージ（Boto3利用）

import boto3
from datetime import datetime

def assume_jit_role(role_arn, session_name):
    """
    一時的な権限昇格をリクエストする関数
    ※実際にはこの前にSlack等での承認プロセスが必要
    """
    sts_client = boto3.client('sts')
    
    # 1時間の有効期限で一時的なクレデンシャルを取得
    assumed_role = sts_client.assume_role(
        RoleArn=role_arn,
        RoleSessionName=session_name,
        DurationSeconds=3600  # 最大でも1時間で切れるように設定
    )
    
    return assumed_role['Credentials']

# 実際に利用する際は、取得したクレデンシャルを環境変数にセットする
# os.environ['AWS_ACCESS_KEY_ID'] = creds['AccessKeyId']

3. なぜ「1時間」なのか？

JITの肝は 「有効期限」 にある。

もし攻撃者が不正にアクセス権を取得できたとしても、その権限が「1時間後には無効になる」と分かっていれば、彼らの心理的・技術的ハードルは跳ね上がる。さらに、この assume_role の履歴は CloudTrail に全て残る。

「誰が」「いつ」「何の目的で」昇格したのか。これをログ監視ツール（DatadogやCloudWatch Logs）で監視し、「昇格リクエストが発生した瞬間にSlackへ通知を飛ばす」設定をしておくだけで、インシデントの検知速度は劇的に向上する。

4. サーバーOS（Linux）におけるJIT的アプローチ：Google Authenticatorの活用

クラウド外、つまりオンプレミスやEC2上のLinuxサーバーでもJITの思想は適用できる。SSHの鍵認証に加え、pam_google_authenticator を用いたMFA（多要素認証）を強制することだ。

/etc/pam.d/sshd に以下の設定を追加し、ログインのたびに物理的なMFAデバイス（スマホ）を要求させる。

# /etc/pam.d/sshd の末尾に追記
# ログイン成功には、鍵認証だけでなくMFAコードも必須とする
auth required pam_google_authenticator.so

これにより、「秘密鍵を盗まれた」という単一障害点（Single Point of Failure）を排除できる。鍵があっても、手元のスマホがなければログインできない。これも一種の「アクセス時の検証によるJIT」と言える。

最後に：セキュリティは「性悪説」で設計せよ

エンジニア諸君、セキュリティは「利便性」と「堅牢性」の綱引きだ。しかし、システムが破壊されてからでは、いくらコードを磨いていても意味がない。

1. 最小権限の原則： 必要な時に、必要な分だけ権限を与える。
2. トレーサビリティ： 誰が何をしたか、後から確実に追えるようにする。
3. 時間制限： 権限は常に「期限付き」であるべき。

今日から、自身の開発環境や運用フローを見直してほしい。「自分は管理者だから大丈夫」という思い込みこそが、最も危険な脆弱性だ。まずは、最も権限の強いアカウントから、多要素認証と最小権限の棚卸しを始めてみてくれ。

現場からは以上だ。何か詰まったら、また相談に来るといい。