【IT知識ゼロからOK】セキュリティと認証の基本 ― 生成AI時代のアーキテクチャ超入門・基礎編

本記事について

当サイトを閲覧いただきありがとうございます。 本記事はシリーズ『生成AI時代のアーキテクチャ超入門』の「ITの基礎知識」編・第5弾として、セキュリティと認証の基本を解説する記事です。

これまでの基礎編で、Webサービスというお店がどう回っているのかを見てきました。今回はそのお店の「防犯」の話です。認証と認可の違い、二段階認証、暗号化といった、本編のセキュリティカテゴリで頻出する言葉を、引き続きお店の例えで押さえていきます。

なぜ防犯の話が必要なのか

そもそもの話として、Webサービスにはなぜ防犯が必要なのでしょうか。

実店舗のレストランなら、防犯の相手は基本的に「店に来られる範囲の人」です。ところがWebサービスというお店は、インターネットに面している時点で、世界中の誰からでもドアに手をかけられる状態に有ります。しかもお店の中には、会員の名前、メールアドレス、場合によってはクレジットカード情報といった、盗まれると大変なものが保管されています。

ここでよく有る誤解が、「うちみたいな無名のサービスを狙う人なんていないでしょ」というものです。気持ちは分かるのですが、残念ながらこれは間違いです。攻撃者は人間の手で一軒一軒狙いを定めているわけではなく、プログラムを使って、見つけたお店のドアを片っ端から自動で試して回っています。有名かどうかは関係なく、鍵の甘いお店から順に入られてしまうのです。なので、どんなに小さなサービスでも防犯は必須になります。

認証 ― 「本人確認」のこと

まず認証（にんしょう）です。英語ではAuthentication（オーセンティケーション）と言い、本編では「認証基盤」「ユーザー認証」のような形で頻出します。

認証とは、ざっくり言えば「本人確認」のことです。お店の例えで言えば、会員制レストランの入口で「会員証を見せてください」とやる、あの確認です。

Webサービスで一番身近な認証は、IDとパスワードによるログインですね。「このIDの本人しか知らないはずのパスワードを知っている。だから本人だろう」という理屈で本人確認をしています。逆に言えば、パスワードが他人に知られてしまうと、その人は堂々と本人として入店出来てしまうわけです。合鍵を作られた状態と同じですね。

認可 ― 「どこまで入れるか」のこと

認証とセットで必ず出てくるのが認可（にんか）です。英語ではAuthorization（オーソライゼーション）と言います。

認可とは、「本人確認が済んだ人が、どこまで入って良いか・何をして良いか」を決めることです。

レストランで考えてみると、会員証で入店した客は、客席には座れますがスタッフルームには入れませんよね。ホール係のアルバイトは客席とキッチンには入れますが、金庫のある店長室には入れない。店長は全部に入れる。「誰なのか」の確認と「どこまで許すか」の設定は、別の話なのです。

Webサービスでも同じで、ログイン（認証）が済んだ後に、「一般ユーザーは自分のデータだけ見られる」「管理者は管理画面に入れる」という権限の割り当て（認可）が行われています。本編に出てくるロール（役割）や権限管理という言葉は、この「誰にどこまで許すか」の設計の話です。

認証と認可は日本語だと一文字違いで、正直かなり紛らわしいのですが（英語でもAuthとAuthzと略されて紛らわしいです・・・）、「本人確認」と「立ち入り許可」は別物、とだけ覚えておけば本編は読めます。

二段階認証 ― 合鍵を作られても防ぐ

最近のサービスでよく求められる二段階認証（多要素認証・MFAとも言います）にも触れておきます。

先ほど、パスワードが漏れると合鍵を作られたのと同じ、という話をしました。実際、パスワードというのは思っているよりも簡単に漏れます。他のサービスから流出した使い回しのパスワードを試される、偽のログイン画面に入力させられる、単純に推測される・・・経路は色々有ります。

そこで、パスワードの確認に加えて、「スマホに届いた6桁の数字を入力してください」のようなもう一段階の確認を重ねるのが二段階認証です。お店の例えで言えば、会員証の提示に加えて「本人の顔写真付き身分証も見せてください」とやるようなものですね。合鍵（漏れたパスワード）を持った攻撃者が来ても、本人のスマホまでは持っていないので、ここで止められるわけです。

暗号化 ― 中身の見えない封筒

もう一つ、本編で頻出するのが暗号化です。

暗号化とは、データを「鍵を持っている人にしか読めない形に変換すること」です。手紙で例えるなら、はがきではなく中身の見えない封筒に入れて送るイメージです。

第1弾で、ブラウザとサーバーが注文をやり取りしているという話をしましたが、この注文は色々な中継地点を経由して運ばれていきます。もしはがきのまま送ってしまうと、経路の途中で覗かれたときにパスワードやカード番号が丸見えになってしまいます。なので現在のWebサービスは、通信を全て暗号化するのが当たり前になっています。URLの先頭の「https」の「s」は、この封筒に入れて送っている印です。

また、通信だけではなく、倉庫（データベース）に保管するデータも暗号化するのが一般的です。万が一泥棒に入られても、持ち出されたものが封筒入りで読めなければ、被害を大きく減らせるからです。

防犯設備だけでは守れない ― 人間を騙す攻撃

ここまで仕組みの話をしてきましたが、実は攻撃の多くは仕組みの穴ではなく、人間を騙すことから始まります。

代表がフィッシングです。銀行や宅配業者を装ったメールで偽のログイン画面に誘導して、本人にIDとパスワードを入力させてしまう手口ですね。これをやられると、どんなに頑丈な鍵を付けていても意味が有りません。「本人が自分から合鍵を渡してしまう」わけですから、防犯設備側では防ぎようがないのです。

お店の例えで言えば、どれだけ立派な金庫と警備システムを入れても、「本社の者ですが」という電話に騙された従業員が金庫を開けてしまったら終わり、という話です。なので実際のセキュリティ対策は、設備（技術）と並行して、騙されても被害が広がらない仕組みを作る方向に進んでいます。先ほどの二段階認証はまさにその代表ですし、本編に出てくる「ゼロトラスト」という考え方も、根っこは「中の人間も騙されている前提で、毎回確認する」という発想だったりします。

セキュリティのよくある勘違い

ここで、初心者の方が持ちやすい勘違いをいくつか整理しておきます。

まず「パスワードを複雑にすれば安全」という思い込みです。複雑にするのは良いことなのですが、現実の事故で一番多いのは複雑なパスワードを複数のサービスで使い回して、どこか1箇所から漏れるパターンです。どんなに複雑な合鍵でも、コピーが出回ってしまえば複雑さは関係有りませんよね。なので優先順位としては、複雑さより「使い回さないこと」と「二段階認証を付けること」の方が上です。

次に「httpsのサイトなら安全」という誤解です。先ほど説明した通り、httpsが保証してくれるのは「通信の中身が覗かれない」ことだけです。通信相手が詐欺サイトでないことまでは保証してくれません。封筒で送れば配達員には読まれませんが、宛先が詐欺師なら意味がない、という話です。実際、最近のフィッシングサイトは大半がhttps対応済みだったりします。

そして、作る側の勘違いとして「セキュリティは完成後に追加すれば良い」というものが有ります。防犯を後付けしようとすると、建物の構造ごと直すような大工事になりがちです。なので本編では、設計の最初の段階から防犯を織り込むという考え方（セキュリティ・バイ・デザインと言います）が前提になっています。セキュリティのカテゴリがシリーズの中で1つの独立したカテゴリになっているのは、それだけ設計の早い段階から効いてくる話だからです。

本編用語との対応表

今回のお店の防犯の例えと、本編で実際に使われる用語の対応を一覧にしておきます。

本編との繋がり

セキュリティの話は、本編では「セキュリティアーキテクチャ」カテゴリでまとめて扱っています。認証・認可の設計、通信とデータの守り方、そして生成AI時代ならではの新しい防犯事情まで、この記事の例えの延長で読み進められると思います。

概要 ― 多層防御とゼロトラストの全体像 ― 生成AI時代のアーキテクチャ超入門senkohome.com/arch-intro-security-overview/

この記事に関連する記事

まとめ

本記事はセキュリティと認証の基本について、お店の防犯の例えで解説しました。如何だったでしょうか。

認証は本人確認、認可はどこまで入れるかの割り当て、二段階認証は合鍵対策のもう一押し、暗号化は中身の見えない封筒。そして何より、攻撃は無差別に、自動で、常に来ているという前提を持ってもらえると、本編のセキュリティカテゴリの話がぐっと現実味を持って読めるようになると思います。

次回の基礎編は最終回として、お店が開店してからの毎日、つまり「開発から運用までの流れ」を解説していく予定です。

シリーズ目次に戻る → 『生成AI時代のアーキテクチャ超入門』の歩き方

それでは次の記事も閲覧いただけると幸いです。