セキュリティ意識の基本 — 新人が守る4原則

Linuxエンジニア養成講座第3回｜全36回・フェーズ1「エンジニアのいろは」の最終回です。
前回までに学んだこと: エンジニアの仕事の全体像と学び方（第1回）、作業記録と報連相（第2回）。
今回学ぶこと: セキュリティ意識の基本。

この記事は座学回です。仮想マシン（VM）の操作はありません。次回の第4回からフェーズ2に入り、いよいよLinuxの実機に触れます。

第2回の末尾で、「作業記録にはサーバーのIPアドレスや認証情報など、機密性の高い情報が含まれることがある」と予告しました。今回はその話を含め、インフラエンジニアが最初に身につけるべきセキュリティの「意識」と「行動」を学びます。

コンテンツ

なぜ新人が最初にセキュリティを学ぶのか
- たった1人のミスが全社に波及する
- 「知らなかった」では済まされない世界
パスワード管理の基本
情報の取り扱い — 何を守り、どう扱うか
最小権限の原則
検証環境と本番環境の区別
- 本番環境で「試す」ことの危険性
- 検証環境を使う習慣
セキュリティインシデント発生時の初動
やってみよう — セキュリティ意識セルフチェック
理解度チェック
まとめ — フェーズ1を終えて
シリーズ一覧

なぜ新人が最初にセキュリティを学ぶのか

たった1人のミスが全社に波及する

インフラエンジニアは、サーバー・ネットワーク・データベースといったシステムの土台を扱います。この土台に穴が空くと、その上で動いているすべてのサービスが影響を受けます。

たとえば、1台のサーバーのパスワードが漏洩したとします。攻撃者がそのサーバーに侵入すると、同じネットワーク上にある他のサーバーへの侵入経路が生まれます。顧客データの漏洩、サービスの停止、ランサムウェアによるデータの暗号化 ―― いずれも1つのパスワード漏洩が起点になりえます。

IPA（情報処理推進機構）が発表した「情報セキュリティ10大脅威 2026」では、ランサムウェア攻撃が組織向け脅威の1位、サプライチェーン攻撃が2位にランクインしています。いずれも、たった1箇所の脆弱性や人的ミスが起点となるケースが多いと報告されています。

「知らなかった」では済まされない世界

「新人だから大目に見てもらえる」は、セキュリティに関しては通用しません。情報漏洩やシステム侵害が発生した場合、「担当者がセキュリティを知らなかった」という理由で損害が軽くなることはないからです。

2022年に改正された個人情報保護法では、個人データの漏洩が発生した場合に個人情報保護委員会への報告が義務化されました。2025年5月に成立したサイバー対処能力強化法でも、基幹インフラ事業者にはセキュリティインシデントの報告義務が課されています。法律の詳細は新人が覚える必要はありませんが、「セキュリティ事故には法的責任が伴う」という事実は知っておくべきです。

だからこそ、コマンドを覚える前にセキュリティの意識を身につけます。技術は後から学べますが、セキュリティ意識のない状態で技術を使うのは、ブレーキのない車を運転するようなものです。

今回扱うのはセキュリティ意識の「4本柱」です。パスワード管理、情報の取り扱い、最小権限の原則、検証環境と本番環境の区別。この4つを軸に学んでいきます。

セキュリティ意識の4本柱。土台にセキュリティ意識、その上に4つの柱（パスワード管理・情報の取り扱い・最小権限の原則・環境の区別）、屋根に安全な実機操作（第4回〜）。神殿のような構造で、土台がなければ柱は立たないことを表現。

パスワード管理の基本

良いパスワードとは何か

「良いパスワード」の定義は、近年大きく変わりました。NIST（米国国立標準技術研究所）の最新ガイドライン（SP 800-63B-4）では、従来の「複雑で定期変更」という考え方が否定され、「長くて使い回さない」ことが重視されています。

主な変更点は以下のとおりです。

長さが最重要: 最低8文字、15文字以上を推奨。複雑さより長さが優先される
特定の文字種の混合強制を廃止: 「大文字・小文字・数字・記号を必ず含めること」という要件は、かえってユーザーに予測されやすいパターン（例: P@ssw0rd）を使わせてしまう
定期変更の強制を廃止: セキュリティ侵害の証拠がない限り、定期的なパスワード変更を要求しない
秘密の質問を廃止: 「母親の旧姓は」「最初のペットの名前は」といった質問はSNSから推測できるため、使用禁止

つまり、P@ssw0rd! のような「複雑だが短い」パスワードよりも、きょうのひるごはんはカレーライスでした のような「覚えやすくて長い」パスフレーズの方がはるかに安全です。パスフレーズとは、複数の単語や文章をつなげた長いパスワードのことです。

パスワードの使い回しが危険な理由

どれだけ強いパスワードを設定しても、複数のサービスで同じパスワードを使い回していたら意味がありません。

理由は単純です。1つのサービスからパスワードが漏洩すると、同じパスワードを使っている他のすべてのサービスに不正ログインされる可能性があるからです。この攻撃手法は「クレデンシャルスタッフィング」と呼ばれ、漏洩したIDとパスワードの組み合わせを片っ端から別のサービスに試す手口です。

「自分のパスワードが漏洩するわけがない」と思うかもしれません。しかし、漏洩するのは「自分の管理」ではなく「サービス側の管理」です。過去に大規模なパスワード漏洩が起きたサービスは数多くあります。Have I Been Pwned（https://haveibeenpwned.com/）というサービスでは、自分のメールアドレスが過去の漏洩に含まれているか確認できます。

パスワード管理ツールという選択肢

「すべてのサービスで異なるパスワードを使う」と言われても、数十のサービスのパスワードを記憶するのは現実的ではありません。そこで使うのがパスワード管理ツール（パスワードマネージャー）です。

パスワード管理ツールは、サービスごとに異なる長く複雑なパスワードを生成・保存してくれるソフトウェアです。覚える必要があるのは、パスワード管理ツール自体のマスターパスワード1つだけです。

代表的なツールをいくつか紹介します。

Bitwarden — オープンソース。無料プランでも基本機能が使える。個人利用の入門に向いている
KeePass — オープンソース。パスワードをローカルファイルに保存する。オフラインでも使える
1Password — 有料だが、企業でのチーム利用に強い。UIが洗練されている

会社で推奨ツールが指定されている場合は、そちらに従ってください。ここでは「こういうツールがある」と知っておくことが目的です。「パスワードを紙に書いてモニターに貼る」のは論外ですが、「ツールを使えば使い回しを防げる」ことは覚えておいてください。

ここで、パスワード管理に関するヒヤリハットを1つ紹介します。

ヒヤリハット: チャットにパスワードを貼った話

あるチームで、検証用サーバーの共有アカウントを新メンバーに伝える必要がありました。担当者は急いでいたため、チャットツールのチームチャンネルに「サーバーのパスワードは xxxxxx です」と投稿しました。

問題は2つあります。まず、そのチャンネルにはプロジェクトに無関係なメンバーも参加していました。次に、チャットの投稿はログとして残り、検索で誰でも見つけられる状態でした。

幸い、すぐに気づいてメッセージを削除し、パスワードを変更しました。しかし、削除前にログをエクスポートしていたメンバーがいたら、パスワードはそのファイルの中に残り続けます。

パスワードをチャットやメールに平文で書いて送るのは厳禁です。パスワードマネージャーの共有機能を使うか、やむを得ない場合はユーザー名とパスワードを別の経路（例: ユーザー名はメール、パスワードは電話）で伝える方法を取ります。最も良いのは、個人アカウントとSSH鍵認証を使い、パスワードを共有しなくていい仕組みを作ることです（SSH鍵認証は第5回・第27回で学びます）。

情報の取り扱い — 何を守り、どう扱うか

機密情報の具体例（インフラエンジニア視点）

「自分は機密情報なんて扱っていない」と思うかもしれません。しかし、サーバーにログインしている時点で、すでに機密情報に触れています。インフラエンジニアが日常的に扱う情報のうち、どれが機密にあたるか確認します。

認証情報: サーバーのパスワード、SSH秘密鍵、API鍵、DBの接続情報、証明書の秘密鍵。漏洩すれば不正ログインやデータ漏洩に直結します。

インフラ情報: IPアドレス、ネットワーク構成図、サーバー構成、使用しているポート番号。これらは攻撃者にとって「設計図」にあたります。設計図があれば、どこを攻撃すれば効率的かがわかります。

顧客データ: 個人情報（氏名・住所・メールアドレス）、決済情報、利用履歴。漏洩すれば個人情報保護法違反となり、損害賠償や企業の信用失墜につながります。

設計・手順書: システム設計書、構築手順書、運用手順書。セキュリティ対策の回避方法や脆弱性の所在が含まれています。

ログ・監査情報: アクセスログ、操作ログ、監視データ。ユーザーの行動パターンや、攻撃の痕跡を隠蔽する手がかりになりえます。

IPアドレスやネットワーク構成は「それ自体が機密情報」です。攻撃者はまず標的のネットワーク構成を把握しようとします。自社のインフラ情報を外部に漏らすことは、攻撃者に地図を手渡すことと同じです。

作業記録に含まれる機密情報（第2回との接続）

第2回で学んだscriptコマンドやTeraTermのログ機能は、ターミナルの入出力をそのまま記録します。この記録の中に、以下のような機密情報が含まれることがあります。

サーバーのIPアドレスやホスト名（SSH接続時のコマンドに含まれる）
cat /etc/shadow の出力（パスワードハッシュ）
DBの接続コマンドに含まれるパスワード（mysql -u root -p<パスワード>）
環境変数に設定されたAPI鍵やトークン
history コマンドの出力に残ったパスワード

作業記録を「便利な作業ログ」としか認識していないと、共有するときに機密情報がそのまま含まれてしまいます。作業記録は「社外秘」として扱い、共有が必要な場合はIPアドレスやパスワードをマスキング（伏せ字に置き換え）してから渡す習慣をつけてください。

マスキングの例を示します。

マスキング前:
  ssh developer@192.168.1.121
  mysql -u admin -pS3cretPass123

マスキング後:
  ssh developer@xxx.xxx.xxx.xxx
  mysql -u admin -p********

テキストの置換は、第8回で学ぶ sed コマンドなどで行えます。スクリーンショットの場合は、画像編集ソフトで不透明な塗りつぶし（モザイクではなく完全に見えなくする塗りつぶし）を使います。モザイクは解除できる場合があるためです。

やってしまいがちなNG行動

機密情報の取り扱いについて、新人がやってしまいがちなNG行動を挙げます。

1. SNSにスクリーンショットを投稿する

「今日の作業で面白いエラーが出た」とスクリーンショットをSNSに投稿したところ、画面の隅にサーバーのIPアドレスやホスト名が写り込んでいた ―― という事例は珍しくありません。仕事に関するスクリーンショットは、どんなに些細に見えても公開しないのが原則です。

2. 個人のクラウドストレージにファイルを保存する

「自宅で作業の続きをしよう」と、手順書や設定ファイルを個人のクラウドストレージに転送する行為は情報漏洩にあたります。会社の管理外にデータが出た時点で、アクセス制御が効かなくなります。

3. 生成AIに機密情報を入力する

エラーの原因を調べるために、サーバーのログをそのままChatGPT等に貼り付ける行為にはリスクがあります。入力したデータがAIの学習に使われる可能性があるためです。生成AIを業務で使う場合は、会社のガイドラインを確認してください。

4. 「社内共有だから大丈夫」と油断する

社内でも「知る必要のない人には見せない」が原則です。第2回で学んだ質問テンプレートにログを貼る場合も、機密情報が含まれていないか確認してから投稿する習慣をつけてください。

最小権限の原則

「必要な権限だけ」を持つという考え方

最小権限の原則（Principle of Least Privilege）とは、「業務に必要な最小限の権限だけを付与する」というセキュリティの基本的な考え方です。

たとえ話で説明します。ホテルに宿泊するとき、フロントから渡されるのは自分の部屋のカードキーだけです。マスターキーを渡されることはありません。マスターキーを持つ必要がないからです。もしマスターキーを落としたら全室が危険にさらされますが、自分の部屋のカードキーなら被害は1部屋で済みます。

最小権限の原則が重要な理由は3つあります。

被害の最小化: アカウントが乗っ取られても、そのアカウントの権限が最小限なら被害も最小限に留まる
ヒューマンエラーの防止: 不要な権限がなければ、操作ミスで重要なファイルを消してしまうリスクが減る
追跡の容易さ: 「誰が何をできるか」が明確になり、問題発生時の原因を特定しやすくなる

root権限の怖さ

Linuxには「root」という最高権限を持つ管理者アカウントがあります。rootはシステム上のあらゆる操作が可能です。すべてのファイルの読み書き・削除、ユーザーの作成・削除、サービスの起動・停止、そしてシステム全体の破壊もできます。

rootで作業することの危険性を1つの例で示します。

意図したコマンド:
  rm -rf /tmp/work

タイプミスしたコマンド（スペースが1つ多い）:
  rm -rf / tmp/work

rm -rf はファイルやディレクトリを確認なしで再帰的に削除するコマンドです。タイプミスにより /（ルートディレクトリ、つまりシステム全体）が削除対象になっています。現代のLinux（AlmaLinux 9含む）では --preserve-root というセーフガードが標準で有効なため、rm -rf / はそのままでは実行されません。しかし、/tmp を消すつもりで /var を消すといったタイプミスはセーフガードでは防げません。rootには「意図と異なるディレクトリを丸ごと削除できる」権限がある、という事実は変わりません。

正しいアプローチは、普段は一般ユーザーでログインし、root権限が必要な操作のみ sudo というコマンドで一時的に権限を昇格させる方法です。sudo を使えば「誰が・いつ・何をしたか」のログも残ります。rootやsudoの実践は第10回で学びます。

「とりあえず全権限」が招くリスク

Linuxでは、ファイルやディレクトリに「誰が読めるか・書けるか・実行できるか」を設定するパーミッションという仕組みがあります。詳細は第11回で学びますが、ここでは概念だけ押さえます。

エラーが出たとき、原因を調べずに「とりあえず全員に全権限を付与する」（chmod 777 というコマンド）で解決しようとするケースがあります。たとえ話でいえば、「鍵がかからないから玄関のドアを外した」ようなものです。確かにエラーは消えますが、誰でもファイルを読み書きできる状態になります。設定ファイルが改ざんされたり、秘密鍵が丸見えになったりするリスクがあります。

なぜ「とりあえず全権限」をやってしまうのか。多くの場合、Permission denied（権限がありません）というエラーが出て、原因を調べるのが面倒だからです。しかし正しいアプローチは、エラーの原因を特定し、必要な最小限の権限だけを付与することです。最初は時間がかかりますが、この癖をつけておくことで、将来セキュリティホールを作らずに済みます。

検証環境と本番環境の区別

本番環境で「試す」ことの危険性

インフラの現場では、環境が大きく3つに分かれます。

検証環境（テスト環境/開発環境）: 新しい設定やコマンドを試す場所。壊しても影響がない
ステージング環境: 本番と同じ構成で最終確認する場所。本番適用前のテスト用
本番環境（プロダクション環境）: ユーザーが実際にサービスを利用している環境。誤操作が即サービス影響につながる

本番環境は「ユーザーが今この瞬間も使っている環境」です。本番環境で「このコマンドを打ったらどうなるだろう」と試すのは、走っている車のエンジンを分解して構造を確認するようなものです。

ここで、もう1つヒヤリハットを紹介します。

ヒヤリハット: 検証のつもりが本番だった

あるエンジニアが、ファイアウォールの設定変更を検証環境で試していました。手順に問題がないことを確認し、次に本番環境に適用する予定でした。ところが、検証環境と本番環境のIPアドレスが似ていたため（例: 検証が 10.0.1.1、本番が 10.0.1.10）、SSH接続先を間違えていたことに気づかず、「検証環境での動作確認」のつもりで本番環境のファイアウォール設定を変更してしまいました。

設定変更により、一部のポートがブロックされ、本番サービスへのアクセスが遮断されました。異変に気づいたのは、監視アラートが鳴った数分後でした。

この事例の問題点は「接続先を確認しなかった」ことです。SSH接続後に hostname（サーバー名を表示するコマンド）を実行して、今自分がどの環境にいるかを確認する習慣があれば防げました。

検証環境を使う習慣

本番環境で作業する前には、以下の確認が必要です。

手順書は第三者がレビュー済みか
問題が起きた場合の切り戻し手順はあるか
バックアップは取得済みか
作業対象の環境は正しいか（ホスト名・IPアドレスを確認）
影響範囲を把握しているか（サービス停止が伴うか、ユーザーに影響があるか）

「検証環境で動作確認してから本番に適用する」が鉄則です。本講座で使うHyper-V上の仮想マシン（AlmaLinux）は、この「壊しても大丈夫な検証環境」そのものです。第4回以降、この検証環境で思う存分コマンドを試していきます。

なお、第1回で紹介した「ターミナルのタブを間違えて本番サーバーで操作してしまう」ヒヤリハットも、環境の区別に関する事例でした。環境を間違えないための工夫として、本番環境のターミナル背景色を赤系にする、プロンプト（コマンド入力の待ち受け表示）の色を変える、接続直後に hostname を確認するといった方法があります。プロンプトの設定は第14回で学びます。

セキュリティインシデント発生時の初動

セキュリティインシデントとは、情報セキュリティに関する事故や事件のことです。新人が遭遇しうる具体例を挙げます。

サーバーのログに、身に覚えのない大量のログイン試行が記録されていた
サーバー上に見覚えのないファイルが存在する
CPUの使用率が異常に高い（マルウェアの可能性）
誤って機密情報を社外に送信してしまった
フィッシングメール（偽のメール）のリンクをクリックしてしまった

こうした場面に遭遇したとき、新人が覚えておくべき原則は「隠さない・消さない・触らない」の3つです。

隠さない: とにかくすぐに報告します。「自分のミスで怒られるかもしれない」という気持ちはわかりますが、報告が遅れるほど被害は拡大します。第2回で学んだ「報告しすぎくらいがちょうどいい」は、セキュリティインシデントでも同じです。むしろ、セキュリティインシデントこそ速報が命です。報告しなかったことが後から発覚すると、インシデントそのものよりも重い処分になることがあります。

消さない: ログファイル、不審なファイル、操作履歴はすべて証拠です。「自分がやったことを消したい」「元に戻せば大丈夫」という気持ちで証拠を削除・上書きしてはいけません。フォレンジック（デジタル鑑識）では、ログや操作履歴から原因を特定します。証拠がなければ原因の特定が困難になります。

触らない: セキュリティ担当者やCSIRT（セキュリティインシデント対応チーム）の指示があるまで、対象のシステムを操作しません。善意の操作であっても、証拠を破壊してしまう可能性があります。判断に迷ったら、上司やセキュリティ担当者に電話してください。

報告時に伝える情報は、第2回の障害報告と同じ型が使えます。

1. 何に気づいたか — 「○○サーバーで不審なプロセスが動いています」
2. いつ気づいたか — 「本日14:30の定期確認で発見しました」
3. どのサーバーか — ホスト名、IPアドレス
4. 現在の状態   — 「ログインしたまま、それ以降の操作はしていません」
5. 自分が行った操作 — 「topコマンドを実行したところ、見慣れないプロセスを発見」

新人のうちは「これはインシデントなのか、それとも正常な動作なのか」の判断がつかないことも多いです。その場合も、自分で判断せず報告してください。「大したことない」と思い込んで放置した結果、重大なインシデントに発展するケースがあります。

やってみよう — セキュリティ意識セルフチェック

以下の4つのシナリオを読み、「自分ならどうするか」を考えてください。テキストエディタやノートに、各シナリオへの対応を書いてみましょう。

シナリオ1: パスワードの共有依頼

先輩から「検証サーバーのrootパスワードをチャットで送って」と頼まれました。あなたはどうしますか。

シナリオ2: ログの共有

障害対応中、上司から「原因調査のためにサーバーのログを共有フォルダに置いてほしい」と言われました。ログにはサーバーのIPアドレスやユーザー名が含まれています。あなたはどうしますか。

シナリオ3: 権限エラーへの対処

設定ファイルを編集しようとしたところ、Permission denied というエラーが表示されました。ネットで検索すると「chmod 777 で解決」という記事が見つかりました。あなたはどうしますか。

シナリオ4: 不審なプロセス

サーバーの状態を確認していたところ、見覚えのないプロセスがCPUを大量に消費していました。ただ、自分の作業には影響がなく、他のサービスも正常に動いているように見えます。あなたはどうしますか。

考え方の例（自分で考えてから確認してください）:

シナリオ1: チャットにパスワードを平文で送ることは避けます。パスワード管理ツールの共有機能が使えるか確認するか、別の安全な方法（例: ユーザー名はチャット、パスワードは口頭）を提案します。先輩の指示であっても、セキュリティルールに反する場合は理由を伝えて代替案を示すことが大切です。

シナリオ2: ログをそのまま置くのではなく、IPアドレスやユーザー名をマスキングしてから共有します。共有フォルダのアクセス権限も確認し、関係者以外が閲覧できない場所に置きます。

シナリオ3: chmod 777 は使いません。まず Permission denied の原因を調べます。ファイルの所有者が違うのか、実行権限が足りないのか。原因に応じて、必要な最小限の権限だけを付与します。わからなければ先輩に相談します。

シナリオ4: 「影響がないから放置」はしません。見覚えのないプロセスはセキュリティインシデントの可能性があります。「隠さない・消さない・触らない」の原則に従い、上司またはセキュリティ担当者にすぐ報告します。自分でプロセスを停止しようとしないでください。

理解度チェック

以下の文が正しければ○、誤っていれば×で答えてください。

Q1. NISTの最新ガイドラインでは、パスワードの「複雑さ」よりも「長さ」が重視されている。

Q2. scriptコマンドで取得した作業記録は、そのまま誰にでも共有して問題ない。

Q3. 最小権限の原則とは、業務に必要な最小限の権限だけを付与するという考え方である。

Q4. セキュリティインシデントが疑われる場合、まず自分で原因を特定してから報告すべきである。

Q5. 検証環境で動作確認した手順であっても、本番環境では作業対象のホスト名やIPアドレスを再確認する必要がある。

解答:

Q1: ○ — NIST SP 800-63B-4では、特定の文字種の混合強制を廃止し、15文字以上のパスフレーズを推奨しています
Q2: × — 作業記録にはIPアドレスや認証情報などの機密情報が含まれる可能性があります。共有する場合はマスキングが必要です
Q3: ○ — 不要な権限を持たないことで、乗っ取りや操作ミスの被害を最小限に抑えられます
Q4: × — 自分で判断せず、すぐに上司やセキュリティ担当者に報告します。原因特定を待っていると報告が遅れ、被害が拡大します
Q5: ○ — 検証環境と本番環境のIPアドレスが似ている場合に接続先を間違えるリスクがあります。必ず確認してから作業を開始します

まとめ — フェーズ1を終えて

今回学んだセキュリティ意識の4本柱を整理します。

パスワード管理: 長さが最重要。使い回しは厳禁。パスワード管理ツールを活用する
情報の取り扱い: 作業記録やスクリーンショットには機密情報が含まれる。共有時はマスキングを忘れない
最小権限の原則: 必要な権限だけを持つ。「とりあえず全権限」は禁止
検証環境と本番環境の区別: 本番で「試す」のは厳禁。接続先は毎回確認する

そして、インシデント発生時は「隠さない・消さない・触らない」。この3原則を守るだけで、被害の拡大を防げます。

ここでフェーズ1全体を振り返ります。第1回ではインフラエンジニアの仕事の全体像と学び方を、第2回では作業記録と報連相を、そして今回はセキュリティ意識の基本を学びました。この3回で身につけたのは、技術そのものではなく「プロとしての基本動作」です。記録を残す習慣、報告する習慣、セキュリティを意識する習慣 ―― これらは、この先33回の技術学習すべての土台になります。

次回からフェーズ2「Linux基礎」に入ります。第4回「Linuxとは何か＋環境確認」では、いよいよ検証環境の仮想マシンに初めてログインし、最初のコマンドを実行します。座学が3回続きましたが、ここからは実機を触りながら学んでいきます。

なお、今回は「意識」と「行動」のレベルにとどめました。Linux固有のセキュリティ技術（SELinux、ファイアウォール設定、脆弱性対応など）は、第28回「SELinux」と第33回「セキュリティ実践」で本格的に扱います。今回学んだ意識があるからこそ、それらの技術を「なぜ必要なのか」を理解した上で使えるようになります。

シリーズ一覧

フェーズ1: エンジニアのいろは（第1〜3回）

第1回エンジニアの仕事と学び方
第2回作業記録と報連相
第3回セキュリティ意識の基本（この記事）

フェーズ2: Linux基礎（第4〜15回）

フェーズ3: ネットワークとインフラ基盤（第16〜27回）

フェーズ4: サーバー構築と運用（第28〜36回）