セキュリティの基礎：認証・認可・暗号化を「事業リスク」として読み解く
セキュリティ事故の多くは、高度な技術的攻撃ではなく基本的な設定不備の放置から起きます。権限管理が甘い、パスワードが平文で保存されている、パッチが当たっていない——原因を遡ると、こうした地味な不備に行き着くケースが大半です。
非エンジニアのM&A担当者やVCキャピタリスト、中小企業の経営者にとって、セキュリティの技術的な実装詳細を理解する必要はありません。しかし「認証」「認可」「暗号化」という3つの基本概念と、それぞれが崩れたときに何が起きるかを事業リスクの言葉で把握しておくことは、投資判断や自社のAI活用を進める上で不可欠です。本稿では、この3概念を軸に、経営が確認すべき最小セットと投資額の考え方を整理します。
認証・認可・暗号化：3つの基本概念を事業リスクで読む
セキュリティの議論は「認証（Authentication）」「認可（Authorization）」「暗号化（Encryption）」という3つの概念に整理すると理解しやすくなります。3つは似た言葉に見えますが、守っている対象がまったく異なります。
認証（Authentication）とは、「あなたは誰か」を確認する仕組みです。 ID・パスワードの入力、指紋認証、SMS認証コードなどが該当します。認証が破られると、攻撃者は正規のユーザーになりすましてシステムに入り込みます。近年増えているのが、他サービスから流出したID・パスワードの組み合わせを使い回して不正ログインを試みる「パスワードリスト攻撃」です。多要素認証（MFA：パスワードに加えてスマートフォンのコードなどを要求する仕組み）を導入していない企業は、この種の攻撃に対して脆弱です。
認可（Authorization）とは、「あなたは何をしてよいか」を制御する仕組みです。 認証で本人確認が済んだあとに、そのユーザーがどのデータにアクセスでき、どの操作を実行できるかを決めます。認証と認可は独立した概念であり、「本人確認はできているが、権限が過剰に与えられている」状態は頻繁に起こります。退職した従業員のアカウントが削除されずに残っている、全社員が経理システムの全データを閲覧できる、といった状態は認可の設計不備です。
暗号化（Encryption）とは、データを第三者が読めない形式に変換する仕組みです。 「保存時の暗号化（at rest）」と「通信時の暗号化（in transit）」の2種類があります。保存時の暗号化はデータベースやストレージ上のデータを暗号化し、万が一データが盗まれても内容を読めなくします。通信時の暗号化は、ブラウザとサーバー間の通信を保護するTLS（Webサイトがhttps://で始まる根拠になっている技術）が代表例です。暗号化されていないデータは、アクセス制御を突破された瞬間にすべて読み取られます。
3つの防御層は独立しているため、1つだけ強固にしても意味がありません。多要素認証を導入していても（認証は強い）、ログイン後に全社員が全データを見られる設計であれば（認可が弱い）、内部不正や乗っ取られたアカウント経由での情報漏えいを防げません。
よくある事故の型と、その原因になる技術的不備
セキュリティ事故のニュースは技術的に見えますが、原因を分解すると典型的なパターンに集約されます。
1. 認証情報の漏えいと使い回し
最も多いのが、漏えいしたID・パスワードが他サービスへの不正ログインに使われるケースです。従業員が複数サービスで同じパスワードを使い回している場合、1サービスの漏えいが全社的な被害に広がります。多要素認証の導入と、パスワード管理ツールの利用がこのリスクを大きく下げます。
2. 権限設定の不備（過剰な権限付与）
退職者アカウントの削除漏れ、業務委託先への過剰な権限付与、開発環境と本番環境で同じ認証情報を使い回すといった運用上の不備です。米国防総省の調査機関MITREが公開する脆弱性分類「CWE（Common Weakness Enumeration）」でも、アクセス制御の不備（Broken Access Control）は繰り返し上位に挙がる問題です（参考：OWASP Top 10）。技術的な難易度は低い一方、運用のルール化が徹底されていない企業ほど発生しやすい類型です。
3. パッチ未適用による既知脆弱性の悪用
ソフトウェアの脆弱性が公表されると、修正パッチが提供されます。パッチを速やかに適用しないシステムは、すでに公開されている攻撃手法でそのまま侵入されます。2017年に世界的な被害を出したランサムウェア「WannaCry」は、数ヶ月前に修正パッチが公開されていた脆弱性を突いたものでした。「知られていない攻撃」より「知られているのに直していない穴」の方が実際の被害に直結しやすいという点は、非エンジニアにも理解しやすい事実です。
4. サプライチェーン経由の侵入
自社のシステムが堅牢でも、業務委託先や利用しているSaaS・OSSライブラリが侵害されると、そこを経由して被害が波及します。近年のインシデントでは、直接の標的ではなく取引先・委託先を踏み台にする手口が増えています。中小企業のAI活用が進むほど、外部のAIツール・APIとの接続点が増え、この種のリスクの評価対象も広がります。
経営が確認すべき最小セット
技術的な詳細まで理解する必要はありませんが、経営者・投資判断者が「確認できる」状態にしておくべき最小限の項目は4つです。
| 項目 | 確認すべき問い | 目安 |
|---|---|---|
| 権限管理 | 退職者・異動者のアカウントは何日以内に無効化されるか | 即日〜1週間以内が望ましい |
| バックアップ | データのバックアップ頻度と、復元テストを実施した最終日はいつか | 定期バックアップ＋年1回以上の復元テスト |
| パッチ運用 | 重大な脆弱性が公表されてから、社内システムに適用するまでの平均日数は | 重大度が高いものは数日〜2週間以内 |
| ログ | 誰がいつ何のデータにアクセスしたかを事後に追跡できるか | 主要システムでアクセスログを保持 |
この4項目に即答できない、あるいは「担当者に聞かないとわからない」状態は、セキュリティ運用が属人化し文書化されていないシグナルです。技術的な巧拙以前に、運用の可視化ができているかどうかが評価軸になります。
投資・買収のデューデリジェンスでは、これらの項目を技術デューデリジェンスの全体像と7つの評価軸で扱う評価軸の一部として確認します。特にSaaS事業者との契約前には、SOC2やISO27001といった第三者認証の有無・取得範囲も合わせて確認すると、自社での検証コストを下げられます。
「セキュリティに投資すべき額」の考え方
「セキュリティにいくら投資すべきか」という問いに万能な正解はありませんが、判断の軸は持てます。
第一に、扱うデータの機微度に比例させるという原則です。個人情報・決済情報・医療情報など、漏えい時の被害が大きいデータを扱う事業ほど投資水準を引き上げます。逆に、機微性の低い情報しか扱わないサービスに過剰な投資をする必要はありません。
第二に、「事故が起きた場合の想定被害額」と「対策コスト」を比較するという発想です。情報漏えいが発生した場合、調査費用・顧客への通知費用・信用毀損による解約・場合によっては行政対応まで発生します。基本的な対策（多要素認証の導入、権限管理の整理、パッチ運用のルール化）は多くの場合、比較的低コストで導入でき、投資対効果が高い領域です。逆に高度な脅威検知システムのような投資は、事業規模・扱うデータの機微度が一定水準を超えてから検討するのが実務的です。
第三に、セキュリティ投資は「一度導入して終わり」ではなく運用コストを含めて考える必要があります。ツールを導入しても、パッチ適用や権限の棚卸しを継続的に行う体制がなければ、時間とともに形骸化します。中小企業がAI活用を進める際に「社内にAIがわかる人材がいない」という課題を抱えるのと同様に、セキュリティ運用も継続的に見る人がいなければ機能しません。
DD・AI導入での接続点
セキュリティの基礎理解は、2つの実務局面で直接役に立ちます。
投資・買収のデューデリジェンスでは、対象企業のセキュリティ運用状況が投資後に発覚しがちな技術リスク10選で扱うような「買収後に発覚する問題」の温床になりやすい領域です。本稿の4項目（権限管理・バックアップ・パッチ運用・ログ）を確認するだけでも、表面的な質問では見えにくいリスクの多くを拾えます。
AI活用・DXを進める中小企業では、社内データを外部のAIツールに接続する際にアクセス制御・データの取り扱いを事前に設計する必要が出てきます。「便利だから」と権限管理を後回しにしたままAIツールの導入を進めると、機微情報が意図しない範囲に露出するリスクが生じます。セキュリティの基礎知識は、AI導入の初期段階でこそ確認しておくべき論点です。
自社のセキュリティ運用の現状を整理したい、あるいは投資・買収前にセキュリティ面の論点を確認したい場合は、お問い合わせからご相談ください。中小企業のAI活用に伴走するTiedWorkspace、投資家・事業会社向けの技術デューデリジェンス支援はTiedPro（投資家向け）・TiedPro（スタートアップ向け）でも提供しています。
関連記事
セキュリティを含む技術基盤の評価は、クラウド選定とも密接に関わります。クラウドサービス入門：AWS/GCP/Azureを「事業上の意思決定」として読み解くでは、コンプライアンス認証の観点も含めてクラウド選択の評価軸を解説しています。
技術DD全体の評価項目は投資家が実施すべき技術デューデリジェンスの全項目、事業判断として蓄積するリスクの正体は技術負債とは結局何か：投資家・経営者向けの再定義も合わせてご覧ください。