【IT用語】「セキュリティ」とは？情報とサービスを守る考え方

結論：「セキュリティ」＝「情報とサービスを、望ましくない事故や攻撃から守ること」

セキュリティには、代表的な3つの目的があります。

• 機密性： 見てよい人だけが情報を見られる。
• 完全性： 情報が勝手に書き換えられない。
• 可用性： 必要な時にサービスを利用できる。

「誰にも触らせない」だけでは、サービスとして役に立ちません。守ることと、正しく使えることの両方が必要です。

認証と認可の違い

似ているようで、役割が違います。

認証：あなたは誰？

ログインなどによって、ユーザーや機器が誰なのかを確かめます。

コンサートで本人確認付きのチケットを確認する場面に近いでしょう。単にチケットを持っているだけでは本人確認にならないため、実際の認証方法はサービスによって異なります。

認可：何をしてよい？

認証した相手が、どの機能や情報を使えるかを判断します。

一般の参加者は客席へ入れても、関係者用エリアには入れません。同じように、一般ユーザーと管理者では使える機能が違います。

ログインできることと、管理者の操作ができることは別の話です。

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

あるサービスからメールアドレスとパスワードが漏れた時、攻撃者は同じ組み合わせを別のサービスでも試します。これを「リスト型攻撃」と呼びます。

対策の基本は次のとおりです。

• サービスごとに異なるパスワードを使う
• パスワードマネージャーを利用する
• 長く推測されにくいパスフレーズを使う
• 多要素認証やパスキーを利用できる場合は有効にする

使い回しを避けるために、すべてを暗記する必要はありません。安全に管理できる道具を使うことも立派な対策です。

サービス側はパスワードをどう保存する？

パスワードをそのまま保存してはいけません。一般には、パスワード保存用の方式でソルトを加え、計算コストを持たせてハッシュ化します。

ハッシュ化は、データを元へ戻す暗号化とは役割が違います。単純にSHA-256へ通すだけでは、パスワード保存として十分ではありません。Argon2idなど、用途に適した方式と設定が必要です。

1つの対策だけに頼らない「多層防御」

完璧な対策を1つ置くのではなく、複数の守りを重ねます。

• アクセス制御： 必要な通信やユーザーだけを許可する。
• 認証・認可： 誰か、何をしてよいかを確認する。
• 暗号化： 通信中や保存中のデータを保護する。
• 更新： 既知の脆弱性を修正する。
• 監視： 異常な動きを見つける。
• バックアップ： 事故や攻撃から復旧できるようにする。

ファイアウォールも、多層防御の一部です。すべての悪い通信を自動で見抜く魔法の壁ではなく、決めたルールに基づいて通信を制御します。

セキュリティは「人を責めるため」ではない

安全な仕組みは、ユーザーが間違える可能性も考えて作ります。

確認画面、権限の分離、入力チェック、操作ログなどを用意し、1回の間違いが大きな事故につながらないようにします。

セキュリティを「面倒な制限」だけで終わらせず、安心して使い続けるための設計として考えることが大切です。

この言葉が会話に出てくるとき

例えば、公開前に「誰が読めて、誰が書いてよいか」を決める会話です。機能追加より先に、見えてはいけない範囲を決めます。

例えば、パスワードや控えファイルの置き場を決めるときです。便利さと、漏れたときの影響を並べます。

勘違いしやすい点

• 専門家だけの仕事： 公開範囲、使い回し、共有端末は、作る人にも使う人にも関係します。
• パスワードを長くすれば十分： 保存の仕方、権限、更新、置き場もセットです。
• 一度設定すれば終わり： 機能を足すたびに、見える範囲が広がり得ます。

守る対象を先に書くと、対策の順番が決めやすくなります。

まとめ

• セキュリティ ＝ 「情報とサービスを、事故や攻撃から守ること」
• 認証 ＝ 「誰なのかを確かめる」
• 認可 ＝ 「何をしてよいかを決める」
• 基本 ＝ 「1つの対策に頼らず、複数の守りを重ねる」

この章で、本書の16用語をすべて紹介しました。

最初は呪文に聞こえた言葉も、役割と使われ方が分かれば、少しずつ自分の言葉に変わっていきます。

ここまでお付き合いいただき、心からありがとうございました！

「安全そう」で済ませて後悔した話

個人開発の初期に、「HTTPSだから大丈夫」「自分しか知らないURLだから大丈夫」と思い込んでいたことがあります。前者は通信の暗号化であり、アプリの設計ミスやXSSを全部防いではくれません。後者は、URLが漏れたり推測されたりした瞬間に前提が崩れます。

そこで今は、次の層を分けて考えています。

• 通信: HTTPS で経路を保護する
• 入力: 想定外の文字列でも壊れない・変なスクリプトを実行しない
• 権限: プレビューや埋め込みでできる操作を最小にする
• 秘密: APIキーや管理用情報を公開HTMLに置かない
• 運用: 依存ライブラリとデプロイ手順を雑に増やさない

セキュリティは「完璧」より穴の種類を減らす作業です。パスワードを長くするのもその一枚で、使い回しをやめる・二段階認証を足す・生成後の保管先を決める、が揃って初めて意味を持ちます。