あなたは、自分のことを「守れるエンジニア」と言えますか？
インフラエンジニアとして働き始めると、最初に覚えるのはサーバやネットワーク、OSコマンドの知識がメインとなる方が多いのではないでしょうか。しかし、セキュリティの観点でシステムを「守れるかどうか」という点も非常に重要です。
セキュリティ製品は増え続け、クラウドは便利になり、構成は複雑になっています。それでもセキュリティ事故は減りません。
それはなぜか。
多くの場合、問題は”技術不足”ではなく、”視点の不足”だからです。
この記事では、若手インフラエンジニアが最初に身につけるべき「現場で使えるセキュリティ思考」を10項目に絞って解説します。設定値や用語の話ではありません。守る側としての”考え方”の話です。
この記事でわかること
- 若手がまず身につけるべきセキュリティ10項目
- 権限・認証・運用で起きやすい事故の入口
- インフラを「作業」ではなく「防御」として考える視点
若手インフラエンジニアが最初に身につけるべきセキュリティ10選
① 最小権限の原則を理解する
インフラセキュリティで、若手に最初に叩き込むのが「最小権限の原則」です。
どれだけFWやウイルス対策を入れても、権限管理が甘ければ一瞬で崩れます。なぜ権限が広いと危険なのか？
多くの現場でよくあるのがこれです。
- とりあえず管理者権限を付ける
- とりあえずグループに入れる
- 一時的な権限を外し忘れる
特にWindows環境では、認証基盤として Active Directory（AD）が使われています。ADは「社内の身分証明書を管理する仕組み」です。ここで権限が広がると、機密フォルダへの意図しないアクセス、サーバ管理権限の拡大、攻撃者の横移動の足場化が発生します。
最終的に狙われるのが Domain Administrator 権限です。これを奪われる＝ドメイン全体を制御されてしまいます。
Domain Administrator 権限 組織のIT環境において最高レベルの権限を持つ管理者アカウント。Active Directoryドメイン内のほぼすべてを操作できる。
最小権限の原則とは？
最小権限の原則（Principle of Least Privilege）は、必要最小限のアクセス権のみを付与するという基本原則です。シンプルですが、事故を防ぐ最も効果的な実務ルールです。
この考え方は、NISTのセキュリティガイドライン（SP 800-53）でも、特権の最小化は基本的な安全管理策として定義されています。つまりこれは”現場のコツ”ではなく、国際的に確立されたセキュリティ原則です。
NIST（National Institute of Standards and Technology） 米国の標準化機関。SP800シリーズなど世界的に参照されるセキュリティガイドラインを策定している公的機関。
【参考】NIST SP 800-53 Rev.5 – AC-6: Least Privilege | CSRC
今日から確認すべき3項目
- 自分のアカウントがどのグループに入っているか把握しているか？
- 管理者権限は作業用アカウントと分離されているか？
- 一時的な権限付与に「外すルール」があるか？
答えられないなら、過剰権限の可能性があります。権限を広く与えるのは簡単ですが、事故が起きたときの影響は計り知れません。「便利だから広く与える」をやめることが、守れるインフラエンジニアへの第一歩です。
最小権限をどのように設計に落とし込むのか、実務でよくある失敗例や具体的な考え方は「最小権限の原則とは？実務での考え方と設計例」で詳しく解説しています。
② Active Directoryの構造を理解する
Windows環境の多くは、認証基盤として Active Directory を利用しています。ADは単なる「ユーザー管理ツール」ではありません。社内のアクセス権限を一元管理する”心臓部”です。
それにもかかわらず、ドメインとは何か曖昧、OUの役割を説明できない、グループ設計を深く考えたことがない、という状態で運用しているケースは少なくありません。
ADは大きく分けて、ドメイン（管理単位の土台）、OU（管理・適用ポリシーの単位）、グループ（権限付与の単位）という役割を持っています。
重要なのは、「権限は基本的にグループ経由で付与される」という点です。ユーザーに直接権限を付ける運用は、後々ほぼ確実にブラックボックス化します。
グループネスト（入れ子構造）の罠
ADではグループの中に別のグループを入れることができます。これが便利である一方、事故の温床にもなります。
例：
- Aグループ → Bグループに所属
- Bグループ → サーバ管理権限あり
この場合、Aグループのメンバーは間接的に管理権限を持つことになります。「1つ追加しただけ」のつもりが、想定外の権限拡大につながるのです。
GPO（Group Policy Object） ドメイン内のPCやサーバーに対して、セキュリティ設定や動作ルールを一括適用する仕組み。
若手のうちに身につけてほしいのは、「このユーザーはなぜこの権限を持っているのか？」を追える力です。どのグループ経由か、どのOU配下か、どのGPOが適用されているか——ここまで説明できれば、構造を理解している側です。説明できない構造は、いずれ事故になります。
まずは自分の環境で、グループのネスト構造と、管理者権限がどこから付与されているかを確認してみてください。そこに、改善ポイントが必ずあります。
③ ドメイン管理者権限の重さを知る
ドメイン管理者権限。これを「ちょっと強い管理者」くらいに思っているなら、その認識は危険です。
ドメイン管理者は、Active Directoryドメイン内の”ほぼすべて”を操作できる権限です。ユーザー作成・削除、グループ変更、GPO改変、サーバー管理、権限の再設計——つまり、組織の認証基盤そのものを制御できます。
ドメイン管理者は、多くの場合攻撃者が最終的に狙う場所となります。インシデント分析で見えてくる攻撃者の行動パターンはほぼ共通しています。
- まずは一般ユーザーのアカウント侵害
- 権限昇格
- 横移動
- 最終的にドメイン管理者の奪取
権限昇格（Privilege Escalation） 通常ユーザー権限から管理者などのより強い権限を奪い取る攻撃手法。
横移動（Lateral Movement） 侵入後に別の端末やサーバーへ次々とアクセス範囲を広げていく行為。横展開と呼ばれることもある。
一度奪えば、全社規模で影響を与えられるからです。近年被害が拡大しているランサムウェア攻撃も、多くはこの権限奪取を経由しています。
ランサムウェア ファイルを暗号化して利用不能にし、復号の対価として身代金を要求するマルウェア。
Microsoftも特権アカウントの分離・最小化・多要素認証の徹底を強く推奨しています。
【参考】最低限の特権の管理モデルを実装する | Microsoft Learn
若手がやりがちな危険な運用
- 普段使いアカウントにドメイン管理者権限を付与
- 作業後に外さない
- 管理者用アカウントを分離していない
これは攻撃者にとって”最高の入口”になります。特にメール経由でアカウントが侵害された場合、管理者権限を持っていれば被害は一気に拡大します。
ドメイン管理者権限は、組織の”核”を握る権限です。強い権限は”持つこと”よりも”管理すること”が難しい——若手のうちにこの事実を理解しておいてください。
④ パッチ管理は「作業」ではなく「防御」
「今月のWindows Updateやっといて」——この一言で終わる現場は多いです。でも、若手のうちに認識を変えてほしいことがあります。
パッチ管理は作業ではありません。防御です。
パッチ OSやミドルウェア、アプリケーションの脆弱性（セキュリティ上の欠陥）を修正する更新プログラム。
つまりパッチ適用とは、既に見つかっている”侵入口”を塞ぐ行為です。放置するということは、ドアが壊れていると分かっているのに修理しないのと同じです。
現実のインシデントで多いのは、ゼロデイ攻撃よりも既知の脆弱性の悪用です。すでに修正パッチが公開済みなのに適用されておらず、そこを突破されたというパターンがほとんどです。つまり、パッチ未適用は「技術不足」ではなく「防御放棄」になり得ます。
ゼロデイ攻撃 修正プログラムが公開される前の脆弱性を突く攻撃。
IPAの「情報セキュリティ10大脅威」でも、脆弱性対策の遅れが重大事故につながることが繰り返し指摘されています。
【参考】情報セキュリティ10大脅威 | IPA 独立行政法人 情報処理推進機構
若手がやりがちな危険な考え方
「止められないから後回し」「影響が怖いから様子見」「検証が大変」——気持ちは分かります。ですが攻撃者は待ってくれません。特に外部公開サーバーは、脆弱性公開後すぐにスキャン対象になります。公開から数日以内に悪用が始まるケースも珍しくありません。
スキャン 攻撃対象を探すためにネットワーク上の機器やポートを自動調査する行為。
若手のうちに身につけてほしいのは、どこまでが管理対象か把握できているか、優先順位を付けられているか、適用状況を説明できるか——という視点です。パッチ管理は”実行力”よりも”管理力”です。管理状況の一覧が出せない状態は、守れていないのとほぼ同じです。
パッチ適用は毎月のルーティンではありません。「侵入口を閉じ続ける行為」＝継続的な防御活動です。
⑤ バックアップは「取る」ではなく「戻せる」
「バックアップは毎日取っています」——この言葉、現場で何度も聞きます。でも本当に確認したいのはそこではありません。
それ、戻せますか？
バックアップは”取得”がゴールではありません。”復元できること”がゴールです。目的はただ一つ、失われた状態から”業務を再開できる状態”へ戻すことです。保存しているだけでは、防御になりません。
ランサムウェア攻撃時に起きる現実
実際の被害現場で起きがちなのは次のパターンです。
- バックアップも同時に暗号化されていた
- 管理者権限で削除されていた
- 復元手順が誰も分からない
- 復元に数日かかることが発覚
「ある」は「使える」とは限らない。IPAのランサムウェア対策資料でも、オフラインバックアップと復元テストの実施が強く推奨されています。
若手が見落としやすい3つの視点
-
分離できているか：バックアップ先が本番環境と同じ認証基盤にある場合、侵害されればまとめて失われます。
-
世代管理されているか：感染後しばらく気づかないケースでは、最新バックアップも既に汚染されている可能性があります。
世代管理 複数の時点のバックアップを保持する仕組み。
-
復元テストをしているか：これが最重要です。実際に戻せるか、どれくらい時間がかかるか、どの順番で戻すべきか——やってみないと分かりません。
RTOとRPOを理解する
RTO（Recovery Time Objective） 復旧までに許容できる時間。
RPO（Recovery Point Objective） どの時点までデータを戻せれば許容できるか。
この2つを意識できると、”バックアップ担当”から”継続性を守る人”に変わります。バックアップは「保存作業」ではなく、最悪の事態でも業務を立て直すための保険です。保険は、いざという時に使えなければ意味がありません。「あるか？」ではなく「戻せるか？」——この視点を持ってください。
⑥ クラウドRBACの過剰権限を避ける
クラウドは便利です。数クリックで環境が作れます。でもその裏で、権限も数クリックで”過剰”になります。
「とりあえずOwner付けておきますね」——この一言が、将来の事故につながります。
RBAC（Role-Based Access Control） 役割（ロール）ごとに権限をまとめ、ユーザーやグループに割り当てるアクセス制御方式。クラウドではこのRBACが基本。
代表的なロール例：Owner（管理者）、Contributor（編集者）、Reader（閲覧者）。便利な仕組みですが、設計を誤ると”全員管理者”状態になります。
なぜ過剰権限が危険なのか
攻撃者の視点で考えてみます。一般ユーザーのアカウントを侵害し、割り当てられているロールを確認する。強い権限があれば即リソース改ざん——というのが典型的な流れです。
リソース クラウド上の仮想マシン、ストレージ、ネットワークなどの構成要素。
Owner権限を持っていれば、仮想マシン削除・バックアップ停止・ログ削除・アクセスキー発行まで可能です。つまり、過剰権限＝被害拡大装置になり得ます。
「急ぎだから強い権限を付与」「後で見直す予定」「一人くらいなら大丈夫」——この”後で”はほぼ来ません。クラウドは変更が速い分、権限の棚卸しをしないと数ヶ月でカオスになります。
棚卸し 現在付与されている権限を一覧化し、不要なものを整理する作業。
実践ポイントは3つです。個人に直接付けない（グループ管理）、常時強権限を持たせない、定期的に棚卸しする。「とりあえずOwner」は設計放棄です。
強い権限を配る人ではなく、強い権限を減らせる人になること——それが”守れるインフラエンジニア”です。
RBACの仕組みと設計の考え方については「RBACとは？クラウド権限管理の基本とAzure RBACの仕組みをわかりやすく解説」で詳しく解説しています。
⑦ ファイルサーバの権限ブラックボックス化を防ぐ
「昔からこのフォルダ構成なんで」——この一言、危険信号です。
ファイルサーバは長年の運用の積み重ねで、誰が何にアクセスできるのか分からない状態になりがちです。これを放置すると、内部不正にも情報漏えいにも弱い環境になります。
ブラックボックス化 内部構造や設定の実態が把握できず、説明も管理もできない状態。
ファイルサーバで起きる典型例：退職者がアクセス可能なまま、不要な全社共有フォルダ、「Everyone フルコントロール」、ネストされたグループ構成で追えない。積み重なるほど、誰も全体像を説明できなくなります。
なぜ危険なのか
攻撃者に侵入された場合、最初に探されるのは共有フォルダです。機密情報が集中している、権限が緩いことが多い、監視が弱い——この3つが理由です。一つのアカウント侵害から、大量の情報流出に発展することがあります。
「触ると怖い」「昔の人しか分からない」「とりあえず現状維持」——これが一番危険です。分からない状態は、守れていない状態とほぼ同じです。
防ぐためにやるべきこと
まず可視化することから始めます。フォルダ構成の一覧化、アクセス権限の出力、グループ構成の整理——”説明できる状態”にします。
次に直接付与を減らす。ユーザー個別に権限を付けると崩壊します。「ユーザー → グループ → フォルダ」という構造を徹底します。
そして定期的に棚卸しする。退職者・異動者の権限が残っていないか、本当にそのアクセスは必要か——年1回でもいい。やるだけで事故確率は大きく下がります。
ファイルサーバは”静かなリスク”です。分からない構成を放置しない姿勢を持てる人が、組織の信頼を積み上げられるエンジニアです。
⑧ メール経由の初期侵入を軽視しない
「うちはUTM入ってますから大丈夫です」——その油断が、入口になります。
実際のインシデントの多くは、メールから始まります。
初期侵入 攻撃者が組織内部ネットワークに最初の足場を築くこと。その手段として最も多いのがメールです。
フィッシングリンク、マルウェア添付、偽の請求書、なりすましメール——インフラの堅牢さより前に、”人”が突破されます。
フィッシング 正規サービスを装い、IDやパスワードを盗み取る詐欺手法。最近は本物そっくりのログイン画面や実在企業を騙る手口が増えている。
一度認証情報が奪われると、メール閲覧・社内情報収集・パスワードリセット・クラウド侵入まで一気に進みます。
なぜインフラ担当が意識すべきか
「それは利用者教育の話では？」——違います。攻撃はこう進みます。
- メールアカウント侵害
- 認証情報の使い回し確認
- 管理ポータルログイン試行
- 権限確認
- 横移動
メール侵害は”入口”、インフラは”本丸”です。
若手が見落としがちな対策視点
多要素認証の徹底：パスワード流出だけでは突破できない状態を作ります。
多要素認証（MFA） パスワードに加え、ワンタイムコードなど複数要素で認証する仕組み。
管理者と通常アカウントの分離：メール用アカウントに管理者権限を持たせない。これだけで被害範囲は激減します。
ログを”見る体制”があるか：不審ログインを検知できなければ、侵害は数週間放置されます。
メールは「利用者側の問題」ではありません。それはインフラ侵害の最短ルートです。入口を軽視しないこと——どれだけ堅牢なサーバーでも、認証情報が奪われれば意味がありません。
⑨ ログ監視は「溜める」ではなく「異常を定義する」
「ログは保存しています」——この言葉だけでは、防御になりません。
ログ監視の本質は、保存することではなく”異常を定義すること”です。
ログ システムやネットワーク上で発生した操作・通信・エラーなどの記録。証拠にはなりますが、見なければただのデータです。
よくある”やっているつもり”状態：サーバーにログは残っている、保存期間も設定している、監査対応はできる——でも、誰が日常的に確認しているか不明、何を異常とするか決めていない、アラート条件が曖昧。これでは侵害は検知できません。
異常を定義するとは
攻撃は必ず”痕跡”を残します。深夜の管理者ログイン、海外IPアドレスからの認証、短時間での大量ログイン失敗、権限変更イベント——これらを「どの条件なら異常か？」と具体的に決めることが重要です。
SIEM（Security Information and Event Management） 複数システムのログを集約・分析し、異常を検知する仕組み。ツールを導入するだけでは不十分で、閾値の設定・アラートへの対応・誤検知の管理まで含めた運用設計こそが本体です。
若手が意識すべき3つの視点
- 「誰が」見るのか決まっているか：責任が曖昧な監視は機能しません。
- 「どれくらいで」気付けるか：侵害から発覚まで数週間というケースは珍しくありません。
- 「発見後どうするか」決まっているか：検知しても動けなければ意味がありません。
ログ監視は「証拠保管」ではありません。”異常を定義し、早く気付く仕組み”です。ログを集める人ではなく、異常を言語化できる人になること——それができると、インフラは”守れる状態”に近づきます。
⑩ 攻撃者視点で構成図を見る習慣を持つ
構成図を見たとき、あなたは何を考えていますか？きれいに整理されているか、IP設計は整っているか、冗長化されているか——それも大事です。
でも、セキュリティの観点で最も重要なのは、「攻撃者ならどこから入るか？」を考えることです。
攻撃者視点 システムを守る側ではなく、侵入・悪用する側の立場で弱点を探す思考方法。設計レビューで見るべきは”美しさ”ではなく、侵入口・権限の広がりやすさ・監視の機能具合・一箇所破られた後の動線です。
構成図は “地図” である
攻撃者にとって構成図は宝の地図です。外部公開サーバー、VPN装置、メールサーバー、認証基盤、管理ネットワーク——「入口」から「王様の部屋」までのルートを探します。
たった一つの質問で変わる
構成図を見るときに必ず自分に問いかけてほしい質問があります。
このサーバーが侵害されたら、次はどこへ行ける？
Webサーバ侵害 → DB接続情報取得、メール侵害 → 管理者パスワード探索、一般端末侵害 → ファイルサーバ横断——この”次の一手”を考える癖がつくと、設計の甘さが見えるようになります。
ネットワーク分離は目的ではない
ネットワーク分離 システムや用途ごとに通信範囲を制限する設計手法。
分離していること自体が安全なのではありません。認証は共通ではないか、管理経路は一本化されていないか、バックアップは同じ権限で触れないか——”突破後”を考えなければ意味がありません。
多くの若手は「言われた通りに構築する人」で止まります。でも攻撃者視点を持てると、「この設計、ここ危ないですよね？」と言えるようになります。それは単なる作業者から守れるエンジニアへの転換点です。これまでの9項目は、すべてこの視点につながっています。
まとめ｜守れるインフラエンジニアになるために
若手インフラエンジニアが最初に身につけるべきセキュリティ10選
- 最小権限の原則を理解する
- Active Directoryの構造を理解する
- ドメイン管理者権限の重さを知る
- パッチ管理は「作業」ではなく「防御」
- バックアップは「取る」ではなく「戻せる」
- クラウドRBACの過剰権限を避ける
- ファイルサーバの権限ブラックボックス化を防ぐ
- メール経由の初期侵入を軽視しない
- ログ監視は「溜める」ではなく「異常を定義する」
- 攻撃者視点で構成図を見る習慣を持つ
セキュリティは製品ではありません。設定でもありません。それは、視点です。
権限をどう配るか、パッチをどう当てるか、バックアップをどう守るか、ログをどう見るか——すべては、「攻撃者ならどう使うか？」を考えられるかどうかで決まります。
10項目を通して伝えたかったことは、高度な技術ではありません。
- 権限を軽く見ない
- パッチを作業にしない
- バックアップを安心材料にしない
- ログを保存で終わらせない
- 構成図を攻撃者目線で見る
すべてに共通するのは、「守る視点を持てるかどうか」です。セキュリティは後付けできません。設計と運用の積み重ねです。
若手のうちにこの視点を持てれば、あなたは”構築できる人”から”守れる人”へ変わります。そしてそれが、現場で一番信頼されるエンジニアです。
あわせてご覧ください：
コメント