【初心者向け】「セキュリティを担保できてる？」とは何なのか

Posted at 2026-08-05

はじめに

こんにちは。とまと🍅好きのエンジニアです。
最近育ててるトマトが赤くなってきて夏だなーと感じています。

それはさておき、私はこの4月に入社し4ヶ月ほど経ちました。
現在、データエンジニアとしてデータ基盤構築の業務に奮闘する毎日を送っています。

業務を進める中で、先輩からレビューや要件定義の際に、ふとこんなことを聞かれる場面がありました。

「この機能って、セキュリティを担保できてる？」

この言葉を聞いた瞬間、「セキュリティ……？」となりました。

一応、権限のある人しか動かせないようにしているけど、それだけでセキュリティを担保できているかを論理的に説明することはできませんでした。

つまり、具体的にどこからどこまでをやれば担保したと言えるのか、体系的な理解が不足していました…。

本記事では、自分のように、「フワッとしたセキュリティの壁」にぶつかっている新人エンジニアに向けて、「セキュリティを担保する」という言葉を具体化していこうと思います！

また、詳しい解説というよりは簡単な概念についての記事になりますので、より詳細を知りたい方は他の方の記事やセキュリティに関する書籍などを読んでみてください！

セキュリティを担保する　＝　100％安心安全なシステムを構築すること

こういうふうに思っていた時期もありました。
しかし、こんなのは、現実的に不可能です。

じゃあセキュリティを担保しているかを聞かれたときに即答できないのはなぜか。
それはセキュリティの言葉の定義を 曖昧なまま話していること が原因だと思いました。

では、開発における「セキュリティを担保する」とは何なのでしょうか？

JIS Q 27000:2019（ISO/IEC 27000:2018）において、情報セキュリティは以下のように定義されています。

情報の機密性，完全性及び可用性を維持すること。

出典：日本産業規格（JIS）- JIS Q 27000:2019 情報技術－セキュリティ技術－情報セキュリティマネジメントシステム－用語 - 日本産業標準調査会（JISC）

つまりこの３つ（機密性、完全性、可用性）を担保することは必須と言えます。
この３つをまとめてCIAといいます。

それでは、このCIAを使うとどうなるのか。
自分の作った機能を以下の3つの観点に分解して考えるとわかりやすいです！

要素	意味	開発で意識すべき具体例
機密性 (Confidentiality)	「見せちゃダメな人には見せない」	・認証（ログイン）や権限管理・「管理者以外は設定画面のURLを直接叩いても弾く」
完全性 (Integrity)	「勝手に変えさせない、壊させない」	・入力値バリデーション・「想定外の文字が入力されたらDB保存前にエラーを返す」
可用性 (Availability)	「いつでも使えるようにしておく」	・バグによるシステムダウンの防止・「重い処理が走っても他の人の画面がフリーズしない」

「セキュリティ大丈夫？」と聞かれたら、この表を思い浮かべて「機密性・完全性・可用性のどこにリスクがあるか？」をチェックすると、やるべきことが明確になります。

自分が実装した対策を報告する際、「はい、セキュリティは大丈夫です！」とだけ答えると、先輩は「本当に分かってるかな？」と不安になります。

開発の報告では、「誰のために、何を守るのか」という思考のプロセスを言語化して伝えることが重要です。

例えば、以下のように言語化ができると観点をセキュリティの観点を抑えられるので、伝わりやすくなります。

「今回の機能では〇〇という（機密性の高い）データを扱うため、
（機密性の観点で）〇〇の権限チェックを実装し、
（完全性の観点で）不正な値が入らないよう〇〇のバリデーションを追加しました。
 権限外のアクセスが弾かれるテストも通っています！」

このように、「何を」「なぜ」「どうやって」守ったのかを根拠を持って伝えると、立派な「セキュリティを担保した報告」になります。

セキュリティ対策は、開発が終わってから「念のため確認するもの」ではなく、設計やコードを書く最初の段階から意識するものです。

最初は完璧にできなくても、まずはコードを書きながら「このデータは誰が見ていいのか？」「変なデータが入ってきたらどうなるか？」を想像することが重要だと思います。

この記事が、先輩の「セキュリティ担保してる？」という質問に対して、しっかりと考えて答えられるように、新米エンジニアの方々のヒントになれば嬉しいです！🍅