CA を学ぶとき、OpenSSL だけでは少し見えにくいものがあります。たとえば、管理者は誰なのか、どの利用者にどのプロファイルで証明書を出すのか、発行後の監査や権限分離をどう考えるのか、といった運用の側面です。そうした“ちゃんとした PKI”の空気を自宅 lab に持ち込みやすいのが EJBCA Community です。公式には Community コンテナを使った quick start が用意されており、Docker で短時間に試せます。 EJBCA の良さは、単に証明書を一枚作るだけで終わらないことです。CA、エンドエンティティ、管理者証明書、プロファイルといった要素が UI 上で見え、PKI を“運用する仕組み”として理解しやすい構造になっています。自宅環境でも、企業や組織で使う CA 製品の手触りをかなり具体的に確認できます。 (docs.keyfactor.com) この記事で扱う内容 今回は Ubuntu VM 上で Docker を使って EJBCA Community を起動し、以下を確認します。 Docker 環境の準備

証明書を自宅で試そうとすると、多くの人はまず OpenSSL を思い浮かべるはずです。秘密鍵を作り、CSR を作り、署名し、必要なら失効や配布を考える。PKI を学ぶ入り口としては王道ですが、運用の現場では証明書のライフサイクル全体を管理できるような仕組みが利用されています。 HashiCorpのVaultは、OpenSSLよりも何段階もステップアップした証明書管理が行えるツールの一つです。また、証明書管理の自動化を前提にした仕組みを味わえるのがVaultの特徴でもあります。誰が、どんな条件で、どんな寿命の証明書を受け取れるかをAPIとポリシーにより制御するという思想で作られています。HashiCorp 公式でも、通常の手動フローを経ずに動的な X.509 証明書を発行できる仕組みとして説明されています。 (HashiCorp Developer) 今回は、このVaultによる証明書管理サーバーを実際に構築し証明書管理の基本やVaultについて学んでいきたいと思います。 この記事で扱う内容 今回は Ubuntu VM 上に検証用の Vault サ

組み込みソフトウェアの脆弱性管理で難しいのは、単に「CVE を検出すること」ではありません。難しいのは、その CVE がどのレイヤーに存在し、製品として本当に影響するのかを判断することです。 コンテナを使っている製品であればコンテナイメージ。Linux ベースであれば OS パッケージ。カーネルモジュールやデバイスドライバ。C/C++ で書かれたアプリケーション。さらに、Yocto や Buildroot で取り込まれる OSS、静的リンクされたライブラリ、設定ファイル、起動スクリプト、証明書、秘密情報。 これらを一つのスキャナでまとめて見ようとすると、どうしても粗くなります。逆に、レイヤーごとに「狙うべきもの」と「適した手段」を分けると、検出結果の解釈がかなり楽になります。 SBOM はこの考え方の土台になります。CISA は SBOM を、ソフトウェアコンポーネントとその関係を把握するための情報として位置づけており、脆弱性把握やサプライチェーンリスク管理に利用できます。NIST SP 800-161 Rev.1 も、製品・サービスのサプライチ