この記事の要点
- 第7章は脅威と脆弱性、対策技術、IoTのセキュリティ対策、標準化動向と法制度を扱う章です。
- 暗号・認証の 仕組みの違い と、JC-STARなど 国内制度の名前と目的 の両方が問われやすい分野です(当サイトの見立て)。
- 学習時間の目安は 当サイトの目安 で、合計7〜9時間です。
第7章の全体像
押さえる用語と対比
| 対になる用語 | 違い |
|---|---|
| 共通鍵暗号 / 公開鍵暗号 | 暗号化と復号に同じ鍵を使い高速か、鍵の組を使い鍵配送の問題を解くか |
| ハッシュ / 暗号化 | 元に戻せない要約値か、鍵で元に戻せる変換か |
| 電子署名 / 暗号化 | 秘密鍵で署名し公開鍵で検証するか、公開鍵で暗号化し秘密鍵で復号するか |
| 脅威 / 脆弱性 | 害を与えうる外的な要因か、それにつけこまれる弱点か |
| 境界型防御 / ゼロトラスト | 内側を信頼するか、全てのアクセスを都度検証するか(NIST SP 800-207) |
| 認証 / 認可 | 誰であるかを確かめるか、何をしてよいかを決めるか |
← 表は横にスクロールできます →
第7章を読むときの視点
第7章は、IoT特有の事情を意識して読むと理解しやすくなります。IoT機器は数が多く、長期間現場に置かれ、計算資源や電力が限られ、人が画面で操作しないことが多いという特徴があります。この特徴が、初期パスワードの放置や更新の難しさといった弱点につながります。
対策技術は、守りたい性質(機密性・完全性・可用性)と結びつけて覚えると効率的です。暗号化は機密性、ハッシュや電子署名は完全性と真正性、冗長化やバックアップは可用性、というように対応させると、問題文で守りたいものが示されたときに選択肢を絞れます。
暗号の鍵の使い方は、「誰の鍵を」「何のために」使うかを必ず主語付きで書いてください。「公開鍵で暗号化する」だけでは不十分で、「受信者の公開鍵で暗号化し、受信者の秘密鍵で復号する」と書けるかが理解の目安です。
法制度とガイドラインは改正や新設が続く分野です。制度の名前、運営主体、対象、目的を一覧にし、公式ページで最新の状況を確認する習慣をつけてください。
間違えやすい点
具体例で確かめる:鍵の使い方の早見表
第7章で最も取り違えが多いのは、どの場面で誰の鍵を使うかです。AさんがBさんへデータを送る場面を例に、目的ごとに整理しました。
| 目的 | 送る側(Aさん)が使う鍵 | 受け取る側(Bさん)が使う鍵 | 守る性質 |
|---|---|---|---|
| 内容を秘密にする(公開鍵暗号) | Bさんの公開鍵で暗号化 | Bさんの秘密鍵で復号 | 機密性 |
| 送り主と改ざんなしを示す(電子署名) | Aさんの秘密鍵で署名 | Aさんの公開鍵で検証 | 完全性・真正性 |
| 大量データを速く暗号化する(共通鍵暗号) | 共有した共通鍵で暗号化 | 同じ共通鍵で復号 | 機密性 |
| 改ざんの有無だけ調べる(ハッシュ) | データのハッシュ値を計算 | 受け取ったデータで再計算して比較 | 完全性(単独では送り主は保証しない) |
← 表は横にスクロールできます →
実際のTLSでは、公開鍵の仕組みと証明書でサーバを認証し、鍵交換で共通鍵を決めてから、共通鍵暗号で通信本体を暗号化します。「公開鍵暗号は遅いので鍵の受け渡しに使い、本体は共通鍵で速く暗号化する」という組み合わせを説明できると、個別の用語問題にも応用が利きます。
よくあるミスは、ハッシュだけで「送り主の証明」ができると考えることです。攻撃者はデータとハッシュ値を両方差し替えられるため、送り主を保証するには電子署名やメッセージ認証符号(MAC)のように鍵を使う仕組みが必要です。
他の章とのつながり
第7章は、他の全ての章と関係する横断的な章です。第1章の各層、第2章のクラウドとエッジ、第4章の通信、第5章のデバイス、第8章の運用のそれぞれに、固有の脅威と対策があります。層ごとに代表的な脅威と対策を一つずつ挙げる練習をすると、知識が整理されます。
例えば、デバイス層なら物理的な改ざんと耐タンパ性、通信層なら盗聴と暗号化、クラウド層なら不正アクセスと認証・認可、運用なら脆弱性の放置と更新の仕組み、という対応です。
IoTの脅威の実例としては、初期パスワードのまま放置された機器が乗っ取られ、大規模な攻撃の踏み台にされた事例がよく知られています。こうした事例と対策を結びつけて覚えると、記憶に残りやすくなります。
学習の順番と時間の目安
以下は 当サイトの目安 です。暗号は図を描きながら進めると取り違えを防げます。
- 脅威と脆弱性の代表例を挙げる(1時間)
- 暗号・ハッシュ・署名・PKIを「どの鍵で何をするか」の表にする(2.5時間)
- セキュアブート・更新・ゼロトラストの目的を整理する(1.5時間)
- 国内の制度とガイドラインの名前と目的を覚える(1時間)
- 問題演習(1.5〜2時間)
本番形式の問題は IoT中級の無料お試し で試せます。
確認問題(オリジナル)
問1 電子署名の検証で、受信者が使う鍵として最も適切なものはどれか。
ア:送信者と受信者が共有した、共通の秘密鍵/イ:送信者だけが持っている、送信者の秘密鍵/ウ:受信者だけが持っている、受信者の秘密鍵/エ:送信者が公開している、送信者自身の公開鍵
正解:エ。署名は送信者の秘密鍵(イ)で作ります。ウは暗号文の復号、アは共通鍵暗号やメッセージ認証符号の場面です。
問2 起動時にファームウェアの署名を検証し、改ざんされたものを実行しない仕組みはどれか。
ア:起動の各段階で署名を確かめるセキュアブート/イ:通信経路を暗号化して盗聴を防ぐTLSの利用/ウ:利用者の権限を最小限に絞るアクセス制御/エ:定期的にデータを別の場所へ写すバックアップ
正解:ア。イは通信、ウは権限、エは復旧の対策で、起動時の改ざん検知とは目的が違います。
問3 ゼロトラストの考え方として、最も適切なものはどれか。
ア:一度認証した端末は、以後は検証を省いてよい/イ:社内網の内側は安全とみなし、外側だけを守る/ウ:社内網からのアクセスも信頼せず、都度検証する/エ:ファイアウォールを二重にすれば検証は不要だ
正解:ウ。イ・ア・エは場所や一度の認証を根拠に信頼する境界型の発想で、NIST SP 800-207の考え方と逆です。
よくある質問
暗号の数学は必要ですか?
当サイトでは、アルゴリズムの数学よりも「どの鍵を誰が持ち、何に使うか」を説明できることを優先しています。
法制度はどこまで覚えるべきですか?
制度の名前、運営主体、目的の3点を押さえるのが出発点です。改正が続く分野なので、公式ページで最新の状況を確認してください。
第7章は何から読むべきですか?
脅威を先に読み、それぞれに効く対策を後から対応させると、対策の目的が分かりやすくなります(当サイトの考え)。
SBOMは第7章の範囲ですか?
ソフトウェア部品の把握は脆弱性対応に関わるため、セキュリティと運用(第8章)の両方にまたがる話題です。SBOM の記事で整理しています。
TLSのバージョンの違いは必要ですか?
TLS 1.3(RFC 8446、2018年)がTLSの最新のメジャーバージョンであることと、通信経路の暗号化と相手の認証を担うことを押さえるのが出発点です。
IoT機器の初期パスワード対策では何が求められますか?
機器ごとに異なる初期パスワードにする、初回の利用時に変更を求める、といった対策が基本です。JC-STARの★1の要件でも、推測されやすい共通の初期パスワードを使わないことなどが求められています。
脆弱性が見つかったとき、IoTでは何が難しいですか?
台数が多く設置場所が分散しているため、どの機器が影響を受けるかの把握と、更新の配布に時間がかかります。SBOMで部品を把握し、安全に遠隔更新できる仕組みを用意しておくことが対策になります。
共通鍵暗号の鍵の数はどう増えますか?
n人が互いに共通鍵で通信するには n×(n−1)÷2 個の鍵が必要です。10人なら45個、100人なら4,950個です。公開鍵暗号なら1人1組の鍵の組で済み、鍵の管理が楽になります。
出典・参考
- [1]IETF RFC 8446 The Transport Layer Security (TLS) Protocol Version 1.3(2026年9月27日確認)
- [2]リックテレコム『IoT技術テキスト 第4版』書誌ページ(目次、2026年9月27日確認)
- [3]NIST SP 800-207 Zero Trust Architecture(2020年8月、2026年9月27日確認)
- [4]NIST SP 800-193 Platform Firmware Resiliency Guidelines(2026年9月27日確認)
- [5]IPA JC-STAR(2026年9月27日確認)
- [6]IPA 情報セキュリティ10大脅威 2026(2026年9月27日確認)
本番と同じペースで腕試し
記事の次は、本番形式の問題で。
公式の出題カテゴリの比率どおりに組んだ無料お試しを、登録不要・カード不要で解けます。続きの模試と章別ドリルは買い切りで、月額はかかりません。
あわせて読みたい
当サイトは、モバイルコンピューティング推進コンソーシアム(MCPC)とは関係のない個人が運営する非公式の学習教材です。掲載している問題はすべて当サイトのオリジナルで、実際の試験問題・過去問題・再現問題ではありません。試験の日程・受検料・出題範囲は公式サイト(https://www.mcpc-jp.org/license/ )で必ず確認してください。合格を保証するものではありません。合格の目安は当サイトの推定です。技術・制度の記述は「最終確認日」時点のものです。