.png){kind=small}
Vol.01 社会人ITエンジニアとして最初に身につけるべきセキュリティの超基礎
- mitsuruto32
- 3月4日
- 読了時間: 19分
更新日：4月14日
この記事であなたがやるべきこと
後述する「今日から実践！エンジニア初心者向けセキュリティチェックリスト」について、
「なぜ重要なのか？」「なぜやるのか？」を理解して、
反復的に思い出し、試行し、息をするように実践できるようになること
新社会人ITエンジニアにとって、セキュリティの勉強は短期間で効率よくやりたいもの
ＩＴエンジニアにとって、セキュリティ対策はもはや必須の位置づけです。エンジニア初心者だからといって、「セキュリティは適当でいいよ」、ってことはありません。攻撃者は初心者だからと手を抜いてはくれません。むしろカモとして目を輝かせて狙います。
とはいえ、エンジニアになったばかりの場合、まずはコーディングや機能実装、サーバ構築にミドルウェアのインストールといった「動かすための勉強」から始めますよね。それだけでも理解しなければいけないことが山ほどあります。そんな中、「セキュリティも大事だから勉強しなさい」「今やエンジニアにとってセキュリティは必須だ」とか言われたら、やる気を失ったり気が狂ったりしませんか？私はしました。
そこで、システム開発/運用に携わることになった、社会人になりたてのITエンジニアをターゲットに「社会人ITエンジニアとして最初に身に着けるべきセキュリティの超基礎」というテーマで、万人にとって重要度が高い基本的なものに絞って解説します。
新米エンジニアがセキュリティ基礎知識を押さえるメリット
「セキュリティが重要なのはわかるけど、まずは業務をできるように実装スキルをつけるのが先じゃないの？」
「ある程度のITリテラシーはあるし、セキュリティの常識は持ってるから大丈夫だよ」
こんな思いがあって、セキュリティの勉強に気乗りしない方もいるかもしれませんので、最初に新米エンジニアがセキュリティ基礎知識を押さえるメリットを説明します。
企業に求められるエンジニアになれる
昨今、セキュリティ事故に関するニュースが後を絶たず、企業は細心の注意を払っています。企業としてもエンジニア一人ひとりにもセキュリティの知識は万全としてもらいたい想いがあります。
そうはいっても、ただでさえ技術の進化が速く、勉強することが尽きないのがエンジニア。必要なのはわかっていつつも、セキュリティの学習まで手が回らないという人も少なくありません。技術力があり、業務要件に対応できるだけでなく、セキュリティ知見が豊富で、セキュアなシステムを作れるようになれば、他のエンジニアに差をつけることができ、企業に求められる人材となることができるでしょう。
AI、ダークウェブの発達でサイバー攻撃の参入障壁が低くなり、活発化
AI技術の進展により、脆弱性を悪用するサイバー攻撃を自動生成することができるようになりました。加えて、ダークウェブの匿名性を活かして攻撃ツールの売買も活発化しています。これにより、専門的知識を持たない人でもサイバー攻撃をできる状況になってきています。
実際にデータを見ても、サイバー攻撃件数が右肩上がりになっていることがわかります。
チェック・ポイント・リサーチの調査によると、「2024年第3四半期において、1組織あたりのサイバー攻撃件数が平均1,876件と過去最高を記録し、前年同期比で75%増加した」と報告されています。
直近でも、年末年始に有名企業へのDDoS攻撃のニュースが複数件報じられていました。もはやサイバー攻撃は「明日は我が身」です。自分の会社や担当するシステムがいつ攻撃されてもいいように、エンジニアは適切なセキュリティ知識を持って対策しておく必要があります。
自身のセキュリティ事故で信頼を失うリスクを軽減できる
システムのセキュリティ事故はもちろん、エンジニア自身が情報漏洩やマルウェア感染といったセキュリティ事故を起こしてしまうというリスクがあります。特に受託開発をしているエンジニアがセキュリティ事故を発生させると、発注元からの信頼を失い、大きな不安を与えることでしょう。
セキュアなシステム開発/構築に加え、自身によるセキュリティ事故対策のためにも、基本的なセキュリティ対策について学んでおき、実践できるようにしておくことが重要です。
以上の3点から、エンジニアにとってセキュリティの基礎知識の習得は、実装スキルや業務遂行スキルと同等以上に重要度が高いと言えます。しっかり身に着けることで、リスク対策と自身の市場価値の向上に繋げましょう。
情報セキュリティとは？3要素（CIA）と7要素を紹介
これから「社会人ITエンジニアとして最初に身に着けるべきセキュリティの超基礎」を語るのですが、ここで改めて「情報セキュリティ」の定義を確認します。
「情報セキュリティとは？」と定義を聞かれると、案外パッと説明できないという人も多いでしょう。個々のセキュリティ対策の意義を本質的に理解するためにも、自分が行っているセキュリティ対策が、どんなセキュリティ特性の担保に繋がっているのかを把握するのは大事です。理解が曖昧だと、無駄な対策や的外れな実装になってしまうことがあるからです。
少し堅い内容になりますが、情報セキュリティの定義に自信がない人は、より根本的な理解のためにもこの章を読み飛ばさず読んでいただきたいです。
情報セキュリティの定義
JIS Q 27000:2019（※）によると
情報セキュリティとは「情報の機密性、完全性、可用性を確保すること」
「さらに、真正性、責任追跡性、否認防止、信頼性などの特性を維持することを含めることもある」
と定義されています。特に前半の三つは情報セキュリティの3要素と呼ばれ、頭文字を並べてCIAと言われることもあります。後半の四つを合わせて7要素とされることも多いので、今回はこの7要素についてそれぞれ詳しく紹介します。
※出典：JIS Q 27000:2019 「情報技術―セキュリティ技術―情報セキュリティマネジメントシステム―用語」
機密性（Confidentiality）
機密性とは、許可されたユーザーだけが情報にアクセスできる状態を維持することです。盗聴や不正アクセスを防ぐことで、データの漏えいを防止することが機密性の向上に繋がります。
対策の例：
アクセス制御の強化（RBAC、ABAC）
データの暗号化（AES、TLS/SSL）
完全性（Integrity）
完全性とは、データが正確かつ改ざんされていない状態を保証することです。不正な変更の予防や検知を行う仕組みを作る必要があります。
対策の例：
ハッシュ値を用いたデータ検証
改ざん検知機能を持つ侵入検知システム（IDS）の利用
可用性（Availability）
可用性とは、必要なときに情報やシステムへアクセスできる状態を維持する特性のことを言います。可用性を担保するには、負荷によるリソース枯渇や災害等が発生しても、システムが停止しない仕組みづくりが求められます。
対策の例：
定期的なバックアップと災害復旧計画（DRP）
システムの冗長化（クラスタリング、フェイルオーバー）
負荷分散（ロードバランサ、CDN）
真正性（Authenticity）
真正性とは、情報や通信相手が本物であると確認することを指します。なりすましをしようとする攻撃者では知りえない情報を使うことで、真正性を確かめることができます。
対策の例：
デジタル証明書（PKI）を利用した認証
バイオメトリクス認証（指紋、顔認証）
責任追跡性（Accountability）
責任追跡性とは、事象やユーザーの操作履歴を記録し、不正の発生時に追跡可能にすることを言います。追跡をするには証拠としてログが必要になるため、ログを改ざん/削除されないための仕組みが不可欠です。
対策の例：
監査証跡の記録（AWS CloudTrail）
セキュリティ情報イベント管理（SIEM）の導入
否認防止（Non-repudiation）
否認防止とは、活動の実行者が後から行為を否認できないようにすることと定義されています。該当する行為について、誰が行ったかを確実に記録し、改ざんできないようにすることで否認を防ぐことが出来ます。
対策の例：
デジタル署名を用いた電子文書の認証
タイムスタンプサービス（TSA）を活用
信頼性（Reliability）
信頼性とは、操作や処理の意図と実行した結果が一貫しており、正しい結果を提供することを言います。セキュリティの観点でいうと、利用者による操作ミスや攻撃者による不正行為によって信頼性が損なわれないようにする仕組みが必要となります。
対策の例：
バリデーションの設定
ヒューマンエラーが発生してもデータが消失/破損しない仕組み
操作ミスが発生しにくい分かりやすい画面/ユーザーインターフェース（UI）の実装
情報セキュリティの7要素を知っておくことで、セキュリティの要件定義を担当するときに網羅的に実施項目を整理できるようになったり、自分の行っている対策がどの部分にあたるかを正確に説明できることで周囲にも納得感と信頼感を持ってもらいやすくなったりするなどのメリットがあります。
最低限エンジニアが知っておくべき情報セキュリティの基本原則
前置きが長くなりましたが、本題に入ります。ここでは、技術分野や案件を問わず、共通して知っておくべき情報セキュリティの基本原則を紹介します。現場によって使う技術も情報セキュリティのルールも様々ですが、ここに書いてある内容は押さえておくことをおすすめします。
最小権限の原則
「最小権限の原則（Principle of Least Privilege）」とは、ユーザーやアプリケーションに対して必要最小限の権限のみを付与する原則です。権限が過剰に付与されると、以下のようなリスクがあります。
不正アクセスを受けた際に影響が広がる
誤操作による被害が起きる
セキュリティの文脈でよく言われるリスクは一つ目で、これは広く理解されていると感じます。一方で、身近で発生しやすいのは二つ目の方です。例えば、本来は一般ユーザでもよかったものを管理者ユーザで作業したがゆえに、誤操作で大変なものを削除してしまった、とか。
「こんな原則、言われなくても当たり前のことじゃないか」と思うかもしれません。でも、実際これをやろうとすると、結構面倒なんですよね。マニュアルの手順が特権ユーザ前提だったとか、基本的には一般ユーザで済むものの、ところどころ特権ユーザがないとコケるとか。
慣れてきたエンジニアほど、最小権限の原則を軽視したときのリスクを忘れがちですので、皆さんは常々頭に入れて作業するようにしましょう。
具体的な対策を記載してきます。
極力一般ユーザアカウントを利用し、必要な場合のみ一時的に管理者権限に昇格する： 泥臭い対策ではありますが、面倒でもあきらめずに「必要な時以外は一般ユーザアカウントで作業する」を徹底することが、なんだかんだで一番の対策です。徹底できている現場は少ないと感じますが、これに向き合うことがルートユーザでrm -rf / home/xxx/xxxを実行して涙を流す、みたいな事態を減らすことに繋がります。
デフォルト権限を疑う： よくあるのが、デフォルトで用意された権限セットに不必要な権限がたくさん含まれているパターンです。クラウドの事前定義ロールとかにありがちです。事前定義されたものを使う場合、どんな権限が入っているかは公式ドキュメントからちゃんと確認しておき、不要な権限がたくさんある場合は、少し面倒でも権限をチューニングしたり、カスタムロールを作るなどして付与する権限を絞ることが事故防止に繋がります。
安全な認証情報管理
パスワードやAPIキー等の認証情報は、情報が漏えいすると大変なセキュリティ事故になります。日常的に使うが故に厳しく管理するのは面倒ですが、漏洩時のリスクが非常に大きいため、ちゃんと対策しましょう。
認証情報は「人が使うもの」「システムが使うもの」の二つに分けられますので、それぞれ個別に対策を記載します。
人が使う認証情報の安全な管理のための対策
パスワード生成アプリによる強固なパスワードを常に利用する： パスワードは自分で考えるとどうしても覚えやすいもの、使いまわししやすい単純なものになりやすいので、パスワード生成アプリを利用して生成すると決めてしまうのが良いです。
パスワードの使いまわしを避ける： 「このサービスのパスワード、何にしたっけ？」がわからずに苦しんだ経験があると、覚えやすいもので使いまわしてしまうもの。しかし、今の世の中、いつ自分の利用しているサービスでパスワードの漏えいが起こり、パスワードリスト攻撃用のデータベースにストックされてもおかしくありません。「パスワードはいつか漏えいする」ぐらいに思っておき、使いまわしを避けましょう。
Lastpassや1Passwordといったパスワード管理ツールや、Chromeのパスワードマネージャーを使うのが、管理面とセキュリティ面のバランスが取れた対策になります。
多要素認証（MFA）ができるなら必ず設定する： 多要素認証が設定できる場合は必ずしておきましょう。パスワードはどう管理しても漏えいリスクがあるので、生体認証やデバイスの認証アプリを利用したMFAを最後の砦として使うのが一番セキュアです。認証アプリは色々ありますが、Google Authenticatorを使えば、Googleアカウントに紐づけることで別デバイスへの引継ぎも含めて楽なのでおすすめです。
システムが使う認証情報の安全な管理のための対策
コードや設定ファイルに認証情報を直書き（ハードコーディング）しない：絶対やめましょう。セキュリティ面でもメンテナンス面でも悪です。初心者あるある「環境変数からパスワードを読みだすのが上手くいかなくてハードコーディングしちゃいました」というのは、ローカルの検証環境での練習の時だけにしましょう。
シークレット管理ツールを使う：HashiCorp VaultやAWS Secrets Managerのようなシークレット管理ツールを使い、ここから認証情報を読み出す形です。導入は大変ですが、一元管理や動的シークレットの活用等、メリットはたくさんあります。使ったことがない場合は、一度調べて利用イメージを把握しておくのがおすすめです。
設定ミスを検知する仕組みづくり
実はセキュリティ事故の原因として「設定ミス」は大きな割合を占めます。クラウドストレージの公開設定を誤ってパブリックにしていたとか、データへのアクセス権限付与が不適切で他人のデータも見放題になっていたとか。
人間はミスをする生き物なので、こういった設定ミスを防ぐには、技術レベルや注意力頼みにするのではなく、仕組みで対策するのがベストプラクティスです。
以下が具体的な対策となります。
設定監査の仕組みを構築する：「設定状況を監視し、望ましくないものがあれば通知する」という設定監査の仕組みを持つ製品やサービスを使うのが非常に効果的です。例えば、主要なクラウドサービスプロバイダーでは、セキュリティリスクとなりうる設定を検知するCSPM（Cloud Security Posture Management）と呼ばれるソリューションが用意されています。これにより、サーバーやストレージの意図せぬパブリック公開のような設定ミスを自動で検知できるようになります。
静的解析（SAST）を利用する：SASTを利用することでプログラムのソースコードやバイナリコードを分析し、SQLインジェクションやバッファオーバーフロー等のセキュリティ脆弱性を特定することができます。無償で使えるツールも多く存在しているため、現場で使っていない場合は手元で試してみてください。
新人エンジニアがやりがちなセキュリティのやらかしと対策
ここからは見方を変えて、新人エンジニアがやりがちなセキュリティ関連のやらかしと、その対策について解説します。ある程度慣れたころにやりやすいものを中心に触れていきますので、自信がある人も含めてぜひご一読ください。
Gitに機密情報をPushしてしまう
良く聞くやらかしかもしれませんが、気を抜いているとすぐにやってしまうのがGitへの機密情報Push。パスワードやAPIキー、社内の機密情報等がフォルダに含まれていることをすっかり忘れてうっかり！という事件は、皆さんの周りにも経験者がいるかもしれません。
これも人間の注意力ではなく仕組みで対策しましょう。基本的な対策を紹介します。
.gitignoreでPushしたくないファイルを指定する： フォルダ内に.gitignoreという名前のテキストファイルを作り、Push対象外にしたいファイル名を指定します。フォルダ単位や特定の拡張子での絞り込み等、柔軟かつ効率的に指定が出来ます。特に.envファイルにアクセスキー等を格納したままコミットしてしまう事故は非常によくあるので、「.gitignoreを作るときは脊髄反射で.envを入れる」ぐらいにした方がいいです。
git-secretsで誤Pushを阻止する： .gitignoreで指定するのを忘れた、あるいは間違えた！というときの対策がgit-secretsです。コミット時にパスワードやAPIキー等の機密情報が含まれているのを検知すると、コミットを防いでくれます。
誤Push発生時に備えてgit filter-branchやBFG Repo-Cleanerは練習しておく： 上記対策もむなしく、誤ってPushをしてしまった！そういった事故に備えて、Pushしてしまった後の対処の手順も押さえておきましょう。git filter-branchやBFG Repo-Cleanerを使うことで、機密情報を含むファイル情報を、コミット履歴も含めて消すことが出来ます。機密情報をプッシュしてしまった際には急いでリカバリする必要があるので、その時にまごつかないように、事前に削除手順は練習しておきましょう。
ツールのインストールにまつわるトラブル
エディタやタスク管理ツール、作図ツール等、日常的に使うツールに関して好みやこだわりがあり、新しい環境では真っ先にツールを整えたくなるという人も多いでしょう。しかし、ツールの導入には慎重になってください。現場によっては、利用して良いツールが明示的に指定されていることがあります。
また、ダウンロード時にマルウェア感染するリスクにも注意が必要です。例えば、有名ツールの偽サイトを作って偽広告でマルウェアの感染を促す事例（Notepad++）や、検索エンジン上位に出てきたサイト経由でソフトウェアをダウンロードしたら、中身がマルウェアだった事例もあります。
たかがツールのインストールと高をくくらず、キチンと以下のような対策はしましょう。
新しい環境でツールを利用したい場合は、必ず既存メンバーにルールを確認する： 新社会人だとこれが頭になく、既存メンバーが教え忘れてしまうと、この確認が漏れてしまうことも珍しくありません。「利用可能なツールは制限されているのが普通である」と認識しておき、新しい現場、新しいPCでツールを利用する際には、ソフトウェア導入に関するルールの有無を必ず確認しましょう。
ダウンロード元が公式サイトであると確認を取る： これも超基本です。「公式サイトが英語だとなんか面倒だし抵抗があるので、日本語で解説してくれているサイトから製品サイトに遷移してダウンロードしてます」という人は要注意です。そのサイトが悪意を持った攻撃者のものだった場合、公式によく似た偽サイトに誘導されるリスクがあります。
原則公式サイトから直接ダウンロードを試みることはもちろん、そのサイトが本当に公式なのかが心配なら、該当ツールを紹介するサイトを複数個確認して、どの紹介サイトでもリンク先のサイト名やドメイン名が一致することを確認してからダウンロードするようにすれば、安全度は高まります。
よくある疑問・注意点
Q: ここに書いてあること、大体知ってた。あまりにも初歩的すぎる。もうちょっとレベルの高い話はないのか？
確かに、超基本的なことばかり書いています。しかし、新社会人の身でその発想を持つのは危険です。
というのも、セキュリティの失敗って、大体初歩的なことから起きるんですよね。
今までに見たことありませんか？以下の流れ。
有名企業で影響の大きいセキュリティ事故が発生する
原因が判明され、世の中に発信され、多くのエンジニアに知られる
「こんな有名企業がなんでこんな初歩的なミスしてんだ？？」という旨のつぶやきがXにあふれる
セキュリティ事故は、必ずしも「がっつり防御を固めた企業をスーパーハッカーがぶち破る」構図ではなく、油断した人が作った穴を目ざとく見つけて起きちゃうパターンのほうが多いのです。
なにより、「高度なことが出来てなくてセキュリティ事故に繋がっちゃいました」より、「初歩的だからと手を抜いていたらセキュリティ事故やっちゃいました」のほうが圧倒的にばつが悪いんですよね。
ですから、ベテランや中堅はもちろん、新社会人のエンジニアは「もう知っている」という基礎的な対策でも、「その対策、両手で数えきれないぐらい聞いてきたし、もはや息をするように実践している」ってぐらいオーバーにやってみていいんです。これまでいくつもの諸先輩のセキュリティ事故を見たり、時には自分でやりそうになったりする中で、本当にそう思います。
Q: 書いてある対策を実践しようとしても、自分一人の力ではできない雰囲気です
これは新社会人に限らず、あるあるだと思います。個人レベルの対策はともかく、ツールを使うとかルールの導入が必要なものは、メンバーの1人がやりたいと思ってもなかなか実現しなそうですよね。
じゃあ、そういう現場では何もしないのが吉かというと、そうでもありません。「こういう理由でこういう対策したいです」って言ってみましょう。思いのほか、前向きに取り合ってもらえる可能性もありますし、実践まで至らなくても以下のようなメリットはあります。
やる気や技術レベルが一定量あると思ってもらえる
どういう理由で実践できないのかを知ることができる（お金？時間？技術的な制約？）
何か変えようとしたときに、どんな感じで壁にぶつかるものかを知ることが出来る
よほど現場の雰囲気が悪くなければ、いうだけならタダです。今回書いた対策の中で現場でやってないものがあれば、ぜひ提案してみましょう。
今日から実践！
エンジニア初心者向けセキュリティチェックリスト
ここまで書いてきたセキュリティリスク対策を読者の皆さんに実践してもらうためにも、チェックリストとしてまとめました。現時点でできていないことを確認し、潰しこむのにご活用ください。
最小権限の原則
極力一般ユーザアカウントを利用し、必要な場合のみ一時的に管理者権限に昇格する
デフォルト権限を疑う
安全な認証情報管理
パスワード生成アプリによる強固なパスワードを常に利用する
パスワードの使いまわしを避ける
多要素認証（MFA）ができるなら必ず設定する
コードや設定ファイルに認証情報を直書き（ハードコーディング）しない
シークレット管理ツールを使う
設定ミスを検知する仕組みづくり
設定監査の仕組みを構築する
静的解析（SAST）を利用する
Gitに機密情報をPushしてしまうことへの対策
.gitignoreでPushしたくないファイルを指定する
git-secretsで誤Pushを阻止する
誤Push発生時に備えてgit filter-branchやBFG Repo-Cleanerは練習しておく
ツールのインストールにまつわるトラブルへの対策
新しい環境でツールを利用したい場合は、必ず既存メンバーにルールを確認する
ダウンロード元が公式サイトであると確認を取る
まとめ
今回記載したセキュリティ対策は基本的なものばかりなので、入社時にセキュリティ関連の研修を受けていれば、「どれも聞いたことがあるもので新しい発見がなかった」と思われるかもしれません。でも、何事も基礎の反復は重要です。1回聞いて1回試したぐらいでは100％実施できるようにはなりません。
今回の記事が、新社会人エンジニアのセキュリティ知識/意識の向上に繋がれば非常に嬉しいです。一緒に頑張りましょう！長い記事でしたが、最後までご覧いただきありがとうございました！
