暗号鍵管理
コラム・記事
-
セキュリティ対応の"現在地"を整理する
－ 「セキュリティ」とは言うけれど、いったい何のセキュリティの話をしているのか －本コラムでは、「セキュリティ」という言葉が持つ曖昧さに着目し、その背景と理由を整理した上で、「組織」と「製品」という2つの軸からセキュリティの全体像をとらえ直し、自社のセキュリティ対応の“現在地”を明確にするための考え方を解説します。- 認証・セキュリティ
-
製品セキュリティの最前線【第6回】
製品セキュリティを支える「物理セキュリティ」の考え方第6回では、これまで扱ってきた「管理」「運用」という流れをさらに一歩進め、製品セキュリティを支える土台としての「物理セキュリティ」を取り上げます。 防犯ではなく製品セキュリティの観点で、どのように位置づけ、どのように考えるべきかを整理していきます。- 認証・セキュリティ
-
製品セキュリティの最前線【第5回】
暗号鍵管理、実際にやるなら、なにを決めてどう管理するか
―暗号鍵管理における考え方・設計・運用を整理するここまでの回で見てきたとおり、製品セキュリティにおいて、暗号は「使っているかどうか」よりも「適切に管理され、説明できる状態にあるかどうか」が問われるようになっています。 本コラムでは、暗号鍵管理について、実装技術そのものに踏み込むのではなく、設計・運用の観点からなにを明確にすべきか、どこを優先して決めるべきかを整理します。- 認証・セキュリティ
-
製品セキュリティの最前線【第4回】
暗号は変わる ― 法規要件を守り続けるための
「クリプトインベントリ」と「クリプトアジリティ」第3回では、欧州連合(EU)のCRA(サイバーレジリエンス法)をはじめとする「機密性」「不正アクセス防止」「更新による脆弱(ぜいじゃく)性対処」などの法規が求める基本的なセキュリティ要件が、いずれも暗号機能を前提にしており、暗号鍵や証明書の管理が崩れると、要件そのものが守れなくなるという構造を整理しました。 では、暗号鍵や証明書の管理をきちんと設計すれば、それで安心なのでしょうか。 実際には、ここで避けて通れないもう一つの現実があります。 それが、暗号は将来「変わる」ことを前提とする必要があります。- 認証・セキュリティ
-
製品セキュリティの最前線【第3回】
「暗号技術」を使うのに、なぜ「鍵管理」はいつも後回しにされるのか ― 暗号をただ使うだけでは足りない、見落としがちなポイント製品セキュリティの多くの要求事項が「信頼の基点」をベースにしているのは、第2回で整理した通りです。 製品の正しさの証明や検証、情報の漏洩や改ざんの防止などの要求を満たすためには、「信頼の基点」を備えることに加えて、暗号技術の活用が欠かせません。 しかし、ここで重要なのは、暗号技術が単にどのアルゴリズムを使うか、通信を暗号化しているかという話だけでは終わらない、という点です。本コラムでは、その暗号の使い方と、使う上でつい見落としてしまいがちなポイントをまとめていきます。- 認証・セキュリティ
-
製品セキュリティの最前線【第2回】
製品セキュリティにおける「信頼」の前提をどう作るか
― 要求事項を「設計の軸」に変えるために「暗号化もSBOM※¹もPSIRT※²も必要なのは理解している。 しかし実際には、それらを設計としてどこまで織り込めば、調達や監査で『十分』と言えるのかが見えない」 ――製品セキュリティ対応を進める現場から、こうした声をよく耳にします。
第1回では、製品セキュリティが努力目標ではなく、法規や調達要件として求められる時代に入った背景を整理しました。 本コラムでは一歩進んで、「では、なにをゴールとして設計すればよいのか」という点を、「信頼」という視点から整理していきます。- 認証・セキュリティ
-
製品セキュリティの最前線【第1回】
もはや調達要件となった製品セキュリティ
―セキュリティ法規対応の義務化は「やらされ仕事」なのか？近年、サイバーセキュリティ対応の必要性は、企業のITシステムに限らず、製品そのものに対しても強く求められるようになってきました。一方で、「対応しなければならないと聞いたが、何から手を付けるべきか分からない」「いろいろありすぎて対応する予算の確保が困難」「そもそも本当に対応が必要なのか判断できない」と感じている方も多いのではないでしょうか。
本コラム「製品セキュリティの最前線」では、そうした悩みを持つ方々に向けて、製品セキュリティが求められる背景や法規・制度の考え方を整理しながら、製品セキュリティ対応の本質と実務上の要点をわかりやすく解説していきます。- 認証・セキュリティ
®