【入門編】 IAMにおけるパスワードポリシーの強化 – インフラ・ネットワーク & クラウドセキュリティ防御ガイド

こんにちは！インフラやセキュリティの世界へようこそ。
初めてサーバーに触れたり、システムの裏側の設定を任されたりすると、「なんだか難しそうな言葉がたくさん出てきて不安だな…」って思いますよね。でも、大丈夫です！一歩ずつ、身近な例えから紐解いていけば、誰でも確実にセキュリティの基礎をマスターできます。

今回は、システムを守るための第一歩である「IAM（Identity and Access Management：ユーザー認証と権限管理）」におけるパスワードポリシーの強化について、お話ししていきますね。

—

1. パスワードは「家の鍵」と同じ！なぜ厳しくするの？

突然ですが、みなさんのお家の玄関の鍵を想像してみてください。
もし、その鍵が「1234」という簡単な暗証番号だったり、誰でもすぐに見つけられる場所に予備の鍵が置いてあったりしたら……泥棒に入られてしまいますよね。

サーバーやクラウドの世界でもまったく同じことが言えます。
開発者が使うサーバーや管理画面のパスワードが「password」や「123456」のように簡単なものだと、世界中にいるサイバー攻撃者（悪い泥棒）は、専用のプログラムを使って一瞬でその鍵を破ってしまいます。これを「ブルートフォース攻撃（総当たり攻撃）」や「辞書攻撃」と呼びます。

攻撃者は、人間が考えるよりもはるかに速いスピードで、何万、何百万というパスワードを試してきます。だからこそ、私たちのパスワードは「ピッキングされにくい、分厚くて頑丈な鍵」にする必要があるのです。

—

2. 攻撃者はどうやってパスワードを破る？（知られざるメカニズム）

「自分の作ったサービスなんて、誰も狙わないよ」なんて油断していませんか？
残念ながら、インターネットに繋がっているサーバーは、24時間365日、世界中からの「自動スキャン」にさらされています。

攻撃者はボット（自動巡回プログラム）を使って、次のような手口であなたのサーバーの扉を叩きます。

1. リスト型攻撃: 他のサービスで漏洩した「IDとパスワードの組み合わせ」をそのまま流用して、あなたのシステムでもログインできるか試す。
2. ブルートフォース攻撃: 「admin」や「root」といった管理者アカウントに対し、考え得るすべてのパスワードの組み合わせを自動で高速入力し続ける。

こうした攻撃を防ぐためには、パスワードを「複雑」にするだけでなく、「間違えられたときにロックする仕組み」や「定期的に作り直すルール」を組み合わせることが絶対に欠かせません。

—

3. 実践！堅牢なパスワードポリシーのベストプラクティス

それでは具体的に、Linuxサーバーやクラウド環境（AWSやAzureなど）でどのような設定をすればよいのか、具体的なパラメータを見ていきましょう。

今回は、Linux（UbuntuやCentOSなど）のシステムでよく使われる libpam-pwquality や /etc/security/pwquality.conf といった設定ファイルをイメージしながら、分かりやすく解説しますね。

① パスワードの複雑性を高める

推測されやすい「password123」や「12345678」のような文字列を弾くための設定です。

# /etc/security/pwquality.conf の設定例
minlen = 12       # パスワードの最小文字数は12文字以上に設定する（長いほど破られにくいです）
ucredit = -1      # 最低1文字は大文字を含める
lcredit = -1      # 最低1文字は小文字を含める
dcredit = -1      # 最低1文字は数字を含める
ocredit = -1      # 最低1文字は記号（!や#など）を含める

【優しく解説】
家の鍵に例えるなら、短い棒きれよりも、複雑に溝が彫られたディンプルキーのほうがピッキングしにくいですよね。文字数を増やし、アルファベットの大文字・小文字、数字、記号を混ぜることで、攻撃者が鍵を解読する難易度を跳ね上げることができます。

② アカウントのロックアウト設定（総当たり攻撃の完全防御）

何回もパスワードを間違えたら、一時的にそのドアを開けなくする（鍵穴を凍結する）設定です。これが設定されていないと、攻撃者は無限にパスワードを試せてしまいます。

# /etc/security/faillock.conf の設定例（Linuxの例）
deny = 5          # パスワードを5回連続で間違えたらアカウントをロックする
unlock_time = 900 # ロックされた後、15分（900秒）経過すると自動で解除される

【優しく解説】
泥棒が玄関の鍵の前で、適当な暗証番号を何回もガチャガチャ試していたら、警察に通報されたり、防犯システムが作動して鍵穴自体がロックされますよね。それと同じで、不正なアプローチを検知したら即座にアクセスを遮断するのがこの設定です。

③ パスワードの有効期限と再利用制限

いつまでも同じ鍵を使い回さないためのルールです。

# /etc/login.defs の設定例
PASS_MAX_DAYS   90   # パスワードは最大90日ごとに変更を強制する
PASS_MIN_DAYS   7    # 変更後、最低7日間は連続して同じパスワードに変更できないようにする
PASS_WARN_AGE   14   # 有効期限の14日前にユーザーへ警告メッセージを表示する

さらに、過去に使ったパスワードを再度使えないように制限（履歴の保持）することで、「古い鍵をまた使う」という危険な習慣を防ぎます。

—

4. 現場のインフラエンジニアからのアドバイス：厳しすぎると人間は「メモ」を貼る

ここまで「厳重な鍵にしましょう！」とお伝えしてきましたが、現場で一番気をつけるべきリアルな罠があります。

それは、「パスワードポリシーがあまりにも厳しすぎると、現場のメンバーがメモ用紙にパスワードを書いてモニターに貼り付けてしまう」という問題です。

毎回複雑すぎるパスワードを要求される
30日ごとに必ず変更させられる

こうなると、人間は記憶しきれなくなり、結局セキュリティを台無しにするようなアナログな抜け道（付箋メモ）を作ってしまいます。これは「セキュリティのジレンマ」と呼ばれる現場の大きな課題です。

だからこそ、パスワードポリシーを厳しく設定するのと同時に、「パスワード管理ツール（Bitwardenや1Passwordなど）」の導入をチーム全体で義務付けることが、現代のインフラ・セキュリティ対策のセットとなります。安全な生成と保存はツールに任せ、人間は複雑なパスワードを覚えるストレスから解放されましょう。

—

まとめ

今回は、IAMにおけるパスワードポリシーの強化について、お家の防犯に例えて解説しました。

パスワードは長く、複雑に（文字種を混ぜる）
連続失敗時はアカウントをロックして総当たり攻撃を防ぐ
定期的な変更と、過去のパスワードの使い回しを禁止する
ただし、厳しくしすぎて「付箋メモ」が生まれないよう、管理ツールの導入もセットで行う

セキュリティの基本は、こうした地道な設定の積み重ねです。一つひとつの意味を理解して設定していけば、あなたのシステムは必ず堅牢な要塞へと生まれ変わります。

一歩ずつ、確実に安全な環境を作っていきましょう！応援しています！