JANOG とは JApan Network Operators' Group を意味し、インターネットに於ける技術的事項、および、それにまつわるオペレーションに関する事項を議論、検討、紹介することにより日本のインターネット技術者、および、利用者に貢献することを目的としたグループです。
(www.janog.gr.jp より引用 )
JANOG53 では最終的に 3000 名を超える実入場者を数え、現地参加として過去最高の規模となりました。
(以下、JANOG53 を J53、JANOG53 会場ネットワークチームを J53NOC と略します。)
全日程終了後のネットワークチーム懇親会後に記念撮影
J53 では、諸事情によりかつてないほど非常にタイトなスケジュールで結成され、本番 1 ヶ月前の 2023 年 12 月中旬にチームが発足し前回となる J52(長崎)のネットワークチーム再招集 + 手練れのエンジニアに声をかけるという形でメンバーを集め、総勢 56 名(大人 35 名 学生 21 名)の顔ぶれとなりました。
以下のようにチームを細分化し、各チームで自律分散的にミーティングや構築を行い、無事に本会議終了まで駆け抜けることができました。
ここからは、サイバートラストが主に関わったサーバーチームの活動についてご紹介します。
会場ネットワークの提供に必要な機材等は各社から借用やご提供を受けています。例えば AP チームの話になりますが、アクセスポイント約 60 台は Cisco からお借りしています。サーバーチームで使用する機材としては、サーバーを MIXI から 2 台、NTT コミュニケーションズから 2 台、ディスプレイ 3 台を NTT 西日本、VMware ESXi・vCenter のライセンスを Cisco からお借りしました。
写真は実際に会場に設置したサーバーの実物の写真です。会場での一時的なサーバー設置ですが、耐震ベルトでしっかりと固定し、排気を向かい合わせにする設置方法にも配慮しています。
サイバートラストからは物品の提供ではなく、AlmaLinux 開発エンジニアを 1 名派遣し、OS に全面的に AlmaLinux 9 を採用してもらい構築・運用上のサポートを提供するという形で協力しました。前述の通り VMware ESXi のライセンスをお借りしていますので、VMware 上に用途ごとの AlmaLinux VM を構築するという形でサーバー構築を行いました。
サーバーチームで提供したサービスは主に以下のようなサービスです。ネットワークの稼働に必須なサービスと、オプショナルな管理・運用を楽にするためのサービスに分かれています。
また、実際の会場での構築の前に、事前検証目的にさくらインターネットよりさくらのクラウドをご提供いただきました。DHCP サーバーを構築するにあたり、DHCP クライアントも稼働させて動作を検証する必要があるため、柔軟な構成を実現できるさくらのクラウドは大変便利でした。重ねてお礼申し上げます。
ここで、各サービスについて、一部だけですが簡単に解説します。各サービスは事前に大人チームが勉強会を開催して学生を指導し、実際の構築は学生が主体となって行いました。
各サービスで使用しているソフトウェアは、AlmaLinux 9 の dnf リポジトリに標準で含まれるものを採用しています。
DHCP サーバーには Kea を使用し、来場者用ネットワークには /19 のサブネットで DHCP サービスを提供しました。リース情報は MySQL に保存するという構成です。期間中の最大 IPv4 アドレスリース数は約 2032 でした。IPv6 については RA でアドレス配布を行ったため、DHCP は使用していません。
パフォーマンス面の懸念事項として、本会議 2 日目以降の朝に 1 日目に会場 Wi-Fi に接続し設定が済んでいるクライアントが、開場と同時に入場し短時間に大量のリースが発生することが想定され、リースが追いつくかという懸念があったのですが、会場のチェックイン受付が律速要因となりクライアント数の増加ペースが抑えられたため杞憂に終わりました。
DNS サーバー(フルサービスリゾルバ)には dnsdist と Unbound、そして keepalived を使用し、最終的に以下のような冗長構成で構築しました。当初はもっとシンプルな構成だったのですが、「前回と同じではつまらない、冗長構成にしたい」という学生の強い希望により本番会期中に構成を変更し途中から下図のような冗長構成での運用に変更されました。
構築作業中に AlmaLinux 9.3 のリポジトリに含まれる Unbound より新しいバージョンで追加された機能を使用したいとの声があり、自前ビルドを行って検証も行いました。実際の本番運用ではリポジトリの Unbound を採用したものの、こういった実運用の場面で出てくるフィードバックは AlmaLinux を開発していく上でとても参考になり、これだけでも J53NOC に参加した甲斐がありました。
会期最終日 撤収前にサーバーチーム全員で集合写真を撮影
JANOG 本番会期中は、サーバーチームとしては概ね問題なく AlmaLinux を使用して非常に安定したサービスを提供できました。絶対に落とさないと学生メンバーが豪語(後述のネットワークチームインタビューを参照)していたとおり、公約は実現できたと思います。
AlmaLinux は透明性が高く公平なコミュニティによって開発されており、多数の企業が支援しているため、プロジェクトとしての継続性が高い Linux OS です。サイバートラストは AlmaLinux OS Foundation のプラチナスポンサーとして AlmaLinux コミュニティに参加しており、ネットワーク用途での利用においても長期にわたって安心して利用できるよう、さらなる品質向上を目指してまいります。
本記事で紹介したのは、J53NOC の活動のほんの一部です。更に詳しい情報は JANOG 公式のインタビュー記事のほか、さくらの夕べでの発表の記事や、J53NOC メンバーの書いたブログなどでぜひご覧になってください。
IEC62443 は、サイバーセキュリティ対策要件の業界横断的に共通項を網羅してある一方で厳しすぎる側面もあります。サイバーセキュリティ対策を検討する上で、情報資産の重要性(想定被害と影響範囲)と対策に掛けるコストのバランスが重要になります。例えばデジタル体温計と電力インフラを制御するような機器と同じセキュリティ要件を強制するのはナンセンスであることは説明するまでもないでしょう。IEC62443 はそもそも重要インフラ防御を想定して策定されていたため、家庭用機器などには過重規格であることは事実です。そこで、各国とも一般家電など、サイバーセキュリティ攻撃対象になりにくいもの、攻撃されても被害が限定的もしくは軽微と想定される機器向けのラベリング制度も策定しています。
いずれも I EC62443 の規格よりは要件を緩和しているものの、対象機器が無線機器(日本の場合は技適対象製品)から一般家電まで広がっています。
サイバーセキュリティ対策は多岐にわたり、ゼロトラストアーキテクチャに必須の信頼の基点の運用や内部犯(内部作業ミス含む)によるものなども対策が必要です。近年、脆弱性対応の不備に起因する被害が増加し、脅威の上位を占めていることから、脆弱性対策が最優先課題になっています。
IPA が毎年情報セキュリティ 10 大脅威を発表しており 2023 年組織に対する脅威の 1 位はランサムウェアによる被害、2 位はサプライチェーンの弱点を悪用した攻撃、3 位は標的型攻撃による機密情報の窃取となっています。
これらはシステムにおける脆弱性を偵察、悪用する事でキルチェーンが成立し被害化したものであり、脆弱性対策が適切になされていれば防げた被害です。サイバーセキュリティを考える上で攻撃者がどのような目的でどのような手段で実行しているかを知ることも重要です。
公安調査庁の公開情報 によれば、脅威主体(サイバー攻撃者)は単なる愉快犯ではなく、金銭・政治・テロ目的が中心であるとされています。中でも APT グループ(Advanced Persistent Threat: 高度で執拗な脅威)は最大の脅威であり、国家などの支援を受けて行われることが多く主に情報を盗むことを目的としています。APT は綿密な計画に基づいて緻密に、広範囲を強い意志を持って攻撃します。
サイバー攻撃はある日突然起きるわけではなく、かなり長い期間を掛けて偵察しシステム全体を把握したうえで、脆弱性とその影響力を特定し攻撃手段を設計します。攻撃手段の設計までに 6 か月から 1 年程掛けていると言われています。近年日本ではシステムに対する偵察行動が1IP アドレスあたり 1 日 8,000 件近く観測されており、99.9% が海外から行われていることが 警察庁 から公表されています。偵察行動そのものは脅威ではないが、脆弱性が特定され武器化されるとキルチェーンが次のステージに進み標的型、フィッシングなどの攻撃手段へ移行してしまいます。
次回は、IoT 機器がサイバー攻撃に狙われる理由と欧州サイバーレジリエンス法案がもたらす影響について解説します。
今回改訂された本ガイドラインにおいては「なりすまし」による不正アクセスと、その対策に関して非常に多く追記されました。背景として、2024 年度より、パブリッククラウド上でデジタル教科書の導入開始ならびに民間の学習 e ポータルを経由した文部科学省の CBT(Computer Based Testing)システムである MEXCBT(メクビット)※ の運用が本格化することに伴い、ID とパスワードを用いた単一要素認証への危機感の表れと見られます。今後教育現場において不正アクセス事件が増加していく傾向が予測されています。
2023 年 9 月には、クラスメイトの ID とパスワードの一覧表を撮影し、嫌がらせを目的とした不正アクセス事件が発覚しており、今後類似の不正アクセス事件は教育現場において年々増加し、大きな社会問題に発展する可能性を秘めていると考えられます。
(出典)文部科学省「教育情報セキュリティポリシーに関するガイドライン」
本ガイドラインでは、不正アクセス対策として、利用者認証(多要素認証)、端末認証、アクセス経路の監視・制御等を組み合わせたセキュリティ対策を「強固なアクセス制御」と称して表現されています。複数ページに渡って何度も言及されていることから、今回の本ガイドライン改訂において文部科学省が最も伝えたい思いであることが伺えます。
(出典)文部科学省「教育情報セキュリティポリシーに関するガイドライン」
強固なアクセス制御において、「端末認証」については電子証明書を利用する旨が記載されており、電子証明書を教職員ならびに児童生徒が利用する個々の端末へインストールすることにより、電子証明書を持つ端末のみアクセスを許可するといった仕組みです。
(出典)文部科学省「教育情報セキュリティポリシーに関するガイドライン」
また、「強固なアクセス制御」の中の 1 つである「利用者認証(多要素認証)」として、ID とパスワードを用いた認証に電子証明書を用いた認証を加えることにより、多要素認証の環境も実現可能となります。
なお、多要素認証については BLOG:多要素認証(MFA)とは? で詳しく解説しています。
文部科学省は 2024 年 1 月 22 日、2024 年度学校の ICT 化に向けた環境整備に係る地方財政措置について、都道府県・指定都市教育委員会に事務連絡を出しており、2024 年度も自治体が行う 1 人 1 代端末の整備経費として 373 億円、それ以外の学校 ICT 環境整備経費に 1,432 億円の地方財政措置を講じる予定となっています。
(出典)文部科学省「学校 ICT 環境整備に係る地方財政措置(令和 6 年度)
また、新たな教育の ICT 化に向けた環境整備 5 か年計画を中央教育審議会にて検討を進めており、2024 年内には内容が公開される見込みです。これらの動きを踏まえ、校務系・学習系ネットワークの統合ならびゼロトラストの思想を取り入れたシステムへのリプレイス、学校で利用する端末のセキュリティ対策が今後急速に進んでいくものと考えられます。
(出典)文部科学省「GIGA スクール構想の下での校務 DX について~教職員の働きやすさと教育活動の一層の高度化を目指して~」
「サイバートラスト デバイス ID」は、学校現場で多く導入されている ChromeOS(Chromebook)をはじめ、Windows、iPadOS / iOS、Android、macOS に対応しています。
また、電子証明書の配付においても、これから新しい端末を生徒へ配る前であれば、管理者にてキッティング時に電子証明書のインストール、既に端末を生徒へ配布済みであれば MDM(Mobile Device Management:モバイルデバイス管理)を利用した配付または MAC アドレスなどの端末固有の識別子による電子証明書の配付が可能なため、管理者が許可していない端末に電子証明書がインストールされてしまうといったリスクにも対処できます。
「サイバートラスト デバイス ID」は初期費用なし、10 ライセンスからご利用可能で、WEB 申し込みから 10 営業日以内の短期間で導入可能な「サイバートラスト デバイス ID」の導入をぜひご検討ください。
なお、「サイバートラスト デバイス ID」では、 無償で 1 ヶ月間、10 台までの機器で評価いただけるトライアルキット をご提供しております。「使用感を実際に体験してみたい」、「既存の環境で運用できるか検証したい」などのご要望に、是非ともトライアルを通じてデバイス ID をお試しください。
サイバートラストでは、デバイス ID をはじめ「教育情報セキュリティポリシーに関するガイドライン」の要件となっています「物理的セキュリティ」「人的セキュリティ」「技術的セキュリティ」「運用」「評価・見直し」など、情報セキュリティ対策を徹底するには、対策を組織的に統一して推進することが必要であり、そのためには組織として意思統一し、明文化された文書として、情報セキュリティポリシーの基本方針を定めなければなりません。
サイバートラストは、情報セキュリティコンサルティングサービスを通じ、情報資産の棚卸しや規定づくり、そして教職員へのセキュリティ教育などを行っています。数多くの情報セキュリティ対策の相談を受けてきたノウハウで課題解決のお手伝いをいたします。
また、情報セキュリティ対策は「組織の状況」「新たな脅威」「新しい法律の施行」といった社会的な状況に応じて、定期的に直しを行う事で、その有効性を維持することができます。継続的な取り組みとするには、学校や自治体が教職員に対して、コンプライアンス活動と浸透を行い、情報セキュリティ意識と行動を望ましい方向に誘導することが有効です。
無償版 VMware ESXi はオンプレ仮想基盤の定番ハイパーバイザーとして、IT エンジニア(特にインフラエンジニア)であれば一度は触れたか、少なくとも目にしたことのあるハイパーバイザーでしょう。( 筆者も新卒入社後、社内外を問わずあらゆる環境でお世話になってきました。)
今回の提供終了によって、特に無償で高品質な仮想化ソリューションとして無償版 VMware ESXi を利用していた小規模から中規模の企業ユーザーは、新たなハイパーバイザーへの乗り換えを模索する必要があるでしょう。
無償版 VMware ESXi の代替として有力な選択肢として KVM (Kernel-based Virtual Machine カーネルベース仮想マシン ) があります。
KVM は Linux Kernel 内で動作するハイパーバイザーで、オープンソース・ソフトウェアとして開発されているため無償で利用することができます。
無償版 VMware ESX の代替として、機能面でも KVM は同等、あるいは無償版 VMware ESX で制限されていた高可用機能 ( ライブマイグレーションなど ) も KVM であれば無償で利用できます。
最近では AWS や GCP などのパブリッククラウドの基盤として採用されているなど大規模環境での実績もあるため、代替手段として申し分ありません。
KVM は Linux Kernel 上に実装されているため、最近の Linux ディストリビューションであれば特に問題なく利用することができます。しかし、サポート期間などはディストリビューションに大きく依存するため、特に企業で利用する場合は全体の安定性などを考慮して AlmaLinux と KVM を組み合わせるのがオススメです。
AlmaLinux は、無償で利用できるエンタープライズ Linux ディストリビューションです。RHEL(Red Hat Enterprise Linux)と互換性があり、動作の安定性や修正のリリース速度が早いことが特長です。
また、AlmaLinux ではサーバー管理ツール Cockpit( コックピット ) を利用することができるので、VMware vCenter と同じように Web ブラウザから仮想マシンの追加削除などの管理をすることもできます。
無償版 VMware ESXi と AlmaLinux + KVM の比較
無償版 VMware | AlmaLinux + KVM | ||
---|---|---|---|
コスト | 無償 | 無償 | |
サポート期間 | 7 年 | 10 年 | |
機能 | Web 管理ツール | ◯ | ◯ |
対応ゲスト OS | Windows, Linux など | Windows, Linux など | |
メモリ管理機能 | ◯ | ◯ | |
CPU 管理機能 | ◯ | ◯ | |
ライブマイグレーション | X | ◯ | |
ストレージマイグレーション | X | ◯ |
サイバートラストでは、AlmaLinux に対して有償のサポートサービスを提供しています。
万が一トラブルが起きた場合でも日本語で技術サポートを受けることができるため安心して利用できます。
VMware から AlmaLinux KVM へのリプレイスについては、今後も随時ブログなどで情報を発信していきますので、無償版 VMware ESXi の提供終了や、VMware の金額改定でお困りの方は、ぜひご相談ください。
SBOM とは、作成するソフトウェアとそのソフトウェアで利用する外部のライブラリやソフトウェアの⼀覧とライセンス・コピーライト等のメタ情報で構成されるリストを指します。
SBOM を利用することで、ソフトウェア間の依存関係やライセンス情報を把握することが可能です。このため、組織の間で共通の機械可読なフォーマットとして、ソフトウェア情報を管理・活用することができるというメリットがあります。
以下は、A 社がアプリケーション Z の SBOM を作成する例です。
アプリケーション Z の SBOM には、アプリケーション Z に関するソフトウェアの提供者、ライセンス情報や含まれるコンポーネント名等を記載します。
以下は、アプリケーション Z が、B 社のコンポーネント X、OSS コミュニティ C のコンポーネント Y を含んでいる場合の例です。
この場合、A 社が作成するアプリケーション Z の SBOM には、A 社が開発したアプリケーションの情報のほかに、「コンポーネント X が含まれていること」、「コンポーネント Y が含まれていること」を記載します。
SBOM が必要になった背景は、OSS へのサプライチェーン攻撃の増加にあります。サプライチェーン攻撃とは、一般的に製品が製造され、ユーザーに届くまでの物流の一連の流れ(サプライチェーン)を悪用して行われる攻撃のことです。製造過程でマルウェアやバックドアを仕込む攻撃や、ターゲットの仕入先、業務委託先等の関連企業を攻撃し、ターゲットの企業に侵入する攻撃などがあります。
OSS のサプライチェーンは、大きく分けて以下のように構成されます。
開発者には、趣味でオープンソースソフトウェアに貢献している個人や、大きな規模の企業まで様々です。また、ソフトウェアの管理、取得、依存関係等の分析にはリポジトリやパッケージのマネジメントツールが利用されます。そして近年では、ソフトウェアを利用するユーザーはリモートの Git リポジトリ、PyPI、npm などからソフトウェアを入手することが主流です。
このようにオープンソースソフトウェアのサプライチェーンは、多様な開発者、オープンなフレームワークなどによってより複雑なものになっているため、この隙を突いたサプライチェーン攻撃の増加に繋がっているのが現状です。
サプライチェーンに関連する問題には、以下のようなものがあります。
サプライチェーン攻撃などのサイバー攻撃の増加を受けて、ソフトウェアサプライチェーンセキュリティの改善のために SBOM を活用する様々な動きがありました。以下は、直近の世界の動きをまとめた表です。
2021 年 5 月 | バイデン米大統領、「Improving the Nation's Cybersecurity( 国家のサイバーセキュリティの改善に関する大統領令 )」に署名 |
---|---|
2021 年 7 月 | NTIA「The Minimum Elements For a Software Bill of Materials(SBOM の最小構成 )」を公開 |
2022 年 1 月 | OSS のサプライチェーン対策のための ホワイトハウスサミット を開催 (The Linux Foundation、OpenSSF、GAFA などを招集 ) |
2022 年 2 月 | OpenSSF はサプライチェーン問題を改善し安全性を高めるための「Alpha-Omega Project」の開始を発表 ( サイバートラストでは 2021 年 7 月より OpenSSF プロジェクトに参加 ) |
2023 年 4 月 | 米 CISA 「Software Bill of Materials (SBOM) Sharing Lifecycle Report」を公開 米 CISA 「Types of Software Bill of Material (SBOM) Documents」を公開 |
日本でもサプライチェーンセキュリティの改善に向けて、SBOM に関連する動きがありました。
以下は、直近の日本の動きをまとめた表です。
2019 年 9 月 | 経済産業省「 サイバー・フィジカル・セキュリティ確保に向けたソフトウェア管理手法等検討タスクフォース 」( ソフトウェアタスクフォース ) の設立 |
---|---|
2022 年 8 月 | Open Source Security Summit Japan を開催 |
2023 年 1 月 | 経済産業省米国国土安全保障省とのサイバーセキュリティに関する協力覚書に署名
|
2023 年 7 月 | 経済産業省「 ソフトウェア管理に向けた SBOM(Software Bill of Materials)の導入に関する手引 」を公開 |
SBOM を利用する場面について以下にまとめます。
NTIA が公開している Roles and Benefits for SBOM Across the Supply Chain を元に作成しています。
図は、A 社がエンドユーザーにアプリケーション Z を提供する時の例です。
このとき、A 社が「ソフトウェアを提供する人」に当たります。ここでの SBOM は、A 社が作成したアプリケーション Z の SBOM を指します。SBOM には、アプリケーション Z に含まれるコンポーネントとして、B 社のコンポーネント X、OSS コミュニティ C のコンポーネント Y の情報が記載されます。
アプリケーション Z の SBOM は、主に以下の目的のために A 社によって利用されます。
図は、エンドユーザーが、A 社のアプリケーション Z を選定する時の例です。
このとき、エンドユーザーが「ソフトウェアを選定する人」に当たります。SBOM は、A 社が作成したアプリケーション Z の SBOM を指します。※
アプリケーション Z の SBOM は、主に以下の目的でエンドユーザーによって利用されます。
図は、エンドユーザーが、A 社のアプリケーション Z を運用する時の例です。
このとき、エンドユーザーが「ソフトウェアを運用する人」に当たります。SBOM は、A 社が作成したアプリケーション Z の SBOM を指します。※
アプリケーション Z の SBOM は、主に以下の目的でエンドユーザーによって利用されます。
主に以下の目的で利用されます。
※A 社が SBOM を提供していない場合、ソフトウェア解析ツール等を利用してエンドユーザー自身が SBOM を生成する場合もありますが、精度は SBOM 生成ツールによって様々です。
OSS が普及している一方で、ライセンスや利用している OSS の依存関係を管理できていないことが原因で、OSS のサプライチェーンを悪用した攻撃が増加しています。このため、OSS に限らず、ソフトウェアサプライチェーンの透明性を確保するために作られたのが SBOM です。
サイバートラストは、2022 年に The Linux Foundation 参加の OpenSSF へ参加し、OSS のサプライチェーンの改善に取り組んでいます。
日本でも、経産省から「ソフトウェア管理に向けた SBOM の導入に関する手引」が公開されており、各業界での SBOM の活用が期待されます。
後編では、SBOM にはどのような種類があるのか、現在どのような法律、規制があるのかを紹介します。
サイバートラストは、SSL/TLS サーバー証明書を導入・利用される方に役立つツールとして、証明書や CSR の解析を行う「 サーバー証明書 導入サポートツール 」を提供しています。このたび、実験・試行および PQC 理解の一助となることを目的として、PQC に対応したサポートツールのベータ版を提供開始しました。本ツールを使用することで、PQC 証明書についても、その内容(DN 情報、有効期間、シリアル番号、署名アルゴリズム等)を確認いただけます。
「PQC(耐量子計算機暗号)対応 TLS サーバー証明書 サポートツール(ベータ版)」
併せて、簡易にサポートツールがお試しできるよう、サンプルの CSR や証明書も同ページに用意しました。
例えば、サンプル証明書の "dilithium2.crt" (NIST が選定した署名用 PQC である dilithium を利用)をクリックして表示された以下のテキストをコピーし、
サポートツールの「サーバー証明書の内容確認」のページにペーストして「確認」ボタンを押すと、以下のような結果が得られ、署名アルゴリズムとして dilithium2 が利用されていることなどが確認できます。
サンプルとしては、参考として既存の(PQC ではない)rsa2048 や secp384r1 なども置いてあります。
PQC 利用により、CSR や 証明書のサイズがどのように変わるかも感じてみてください。
また、rsa3072_dilithium2 などとあるのは、異なる2つのアルゴリズムを利用した「コンポジット」のサンプルとなります。「コンポジット」については、過去のブログ 第3話: Open Quantum Safe (OQS) project と「ハイブリッド」証明書について をご参照ください。
なお、サポートツールや、サンプルの CSR・証明書の作成では、Open Quantum Safe(OQS) が提供する PQC 対応ライブラリ "liboqs" および PQC 対応 OpenSSL 3 provider "oqs-provider"(いずれも MIT ライセンス ※1,2)を使用しています(PQC 対応 TLS サーバー証明書 サポートツール のページにも同様の旨を記載しています)。
併せて、PQC 対応サポートツールは 2024 年 3 月現在、実験・試行および PQC 理解の一助となることを目的としたベータ版です。動作や各種仕様に対する準拠性、相互接続性、データの安全性、その他を保証するものではなく、機能・動作等が不十分または不安定なこと、予告なしに本サイトを変更や停止等することがあります。開発段階である現状をご理解いただきご試用ください。
サイバートラストは、お客様の PQC 移行や検証の一助になればと、情報発信や PQC 証明書サンプルのご提供 ※3 を行ってまいりましたが、今回のサポートツールの PQC 対応もその一環となります。引続きこれらを進め、安心・安全なデジタル社会の実現に貢献できればと考えております。
参照
東京都産業労働局より CentOS 7 メンテナンス終了の注意喚起が発表されました。
https://www.cybersecurity.metro.tokyo.lg.jp/security/cyberthreat/497/
- CentOS 7 は 2024 年 6 月 30 日を以て、サポート期間が終了となります。
- サポート期間終了後は、仮に重大な脆弱性が発見されたとしても、パッチやアップデートは一切提供されないため、サイバー攻撃の被害を被る可能性が高くなります。
2024 年 6 月末をもって、The CentOS Project による CentOS 7 のメンテナンスが終了します。
メンテナンス終了後は脆弱性の修正がされないため、サイバー攻撃のリスクに晒されることになり、情報流出、のっとり、ランサムウェア被害などの実害が出るおそれがあります。
特に CentOS 7 については世界的にユーザーが多いことから攻撃ターゲットとされることが予想されます。
自社で利用しているサーバー、委託先、子会社などの関係会社で利用しているサーバーの確認と、早急な対策を検討してください。
メンテナンスが終了している CentOS 8 、CentOS 6 ではすでに 2,000 を超える脆弱性が発見されており、サイバー攻撃を受けた際、無防備な状態です。また、CentOS 7 に関してもメンテナンス終了後は大量の脆弱性を内包することになり、非常に危険な状態となります。
80% 超の CentOS 7 保有企業は、すでに CentOS 7 の対策を検討しています。さらに 、60% 超の CentOS 7 保有企業は 他 OS への移行ではなく、何らかの企業サポートを受けての延命を検討しています。
新しい OS への移行はサービスの停止が発生する、エンジニアコストがかかる、計画~検証~作業~試験の時間が足りないなど難しい面も多く、現状では延長サービスを利用してハードウェア寿命まで延命し、ハードウェアと同時にシステムを一新するという手段が現時点では最も現実的な対応策と言えるでしょう。
2024 年 CloudLinux 調べ
サイバートラストでは CentOS の延長サポートと、移行先の選択肢として CentOS と同様に Red Hat Enterprise Linux 互換の MIRACLE LINUX、AlmaLinux 向けのサービスを提供しています。
CentOS 7 のメンテナンス終了でお困りの際はぜひご検討ください。
開発元のメンテナンスサポート終了後は、重大な脆弱性が発見されたとしてもパッチやアップデートは提供されないため、サイバー攻撃の被害を受ける可能性が高くなります。 「CentOSメンテナンス終了」で直面する課題から実際に起きること、対策としてどんな選択肢があるのかまで、過去の例も交えて解説します。(全16ページ)
下記よりメールアドレスをご登録いただく事で資料をダウンロードいただけます。
※ 誤登録を防止するため、ご入力いただいたメールアドレス宛に一度確認メールを送信させていただきます。確認メール内の URL をクリックして頂き、その後資料のご案内をいたします。
目次
EU の主たる決定機関である欧州連合理事会(EU 理事会、または閣僚理事会)と欧州議会は 2023 年 11 月 30 日にデジタル製品のサイバーセキュリティ対応を義務づけるサイバーレジリエンス法案に関して暫定的な 政治合意に達したと発表 しました。EU 理事会と欧州議会の正式な採択を経て、2024 年前半には施行される見込みとなりました。
同法案の対象製品は、既存の EU 規制で定められている医療機器や航空、自動車を除く " すべてのデジタル機器 " が対象となっています。ここで言うデジタル機器とはソフトウェアが動くすべての製品となっており、ネットワークに接続しないデジタル体温計やおもちゃなどもソフトウェア制御が含まれていると対象となります。同法案は、" デジタル機器 " のサイバーセキュリティの欠陥からユーザーや消費者を守るためのもので、違反した企業には巨額の罰金が科される可能性があります。
欧州サイバーレジリエンス法の施行は 2024 年前半で、移行期間が 36 ヶ月と定められています。まだ対応に時間があると感じる方が多いと思いますが、同法に適応するには組織的な対応が必要となり、認定機関の試算では 適合認定までに必要な期間は 28 ヶ月~32 ヶ月程度 とされています。同法の施行が 7 月からと仮定すると移行期間は 2027 年 8 月までとなり、 逆算すると 2024 年 10 月には始めないと間に合いません。
本稿では、サイバーレジリエンス法が及ぼす影響とその対策について概要をまとめて連載で解説します。皆様の対策検討が一日も早く開始され、期日までに対応が完了できる一助となれば幸いです。
サイバーセキュリティに関しては 2018 年 10 月 4 日に ペンス副大統領がハドソン研究所で対中政策に関する演説 を行った事から端を発しています。米中経済摩擦に対し「関税戦争」と「先端技術を巡るテクノロジー覇権争い」の 2 つの側面があります。この演説の中で「優位性を求める競争(Competition for Pre-eminence)」が強調されており、その後 G7 で協調したサイバーセキュリティ法規性の策定へ進み米国政権が交代した後もこの方針は維持され今日に至っています。
以下の図は、法規制に関する流れを時系列でまとめたものです。
2018 年から開始された膨大な規格策定作業は概ね 2022 年に各国で完了し、2023 年では法規制化する立法プロセスまで進みました。G7 の中で先行しているのが欧州であるのは事実ですが、米国、イギリス、日本でも罰則規定等強制力にはバラつきはあるものの規格要件としては同じものを採用しています。
欧州、米国、イギリス、日本とも一見バラバラに策定しているように見えますが、実は規制内容は IEC62443 で共同作業をしており(米国では IEC ではなく ANSI と呼ばれる)、業界問わず IEC62443 がサイバーセキュリティの根幹をなしています。
この規格では、(1)製品を製造する会社のサイバーセキュリティ対応(IEC62443-1 と -2)に加え、(2)製造プロセス制御システムに対する規格(IEC62443-3)、(3)製造する商品の設計開発プロセス、セキュリティ要件(IEC62443-4)と多岐にわたります。
IEC62443 については、組織全体が適応する事が求められていることがご理解いただけると思います。これが適合認定までに 28 ヶ月~32 ヶ月を必要とする所以です。詳細は続編で解説します。
最近、ニュース記事などで目にすることが多くなった「C2PA」という用語、みなさんご存じでしょうか?
正式には「Coalition for Content Provenance and Authenticity」と言って、コンテンツの出所・来歴の認証に関する技術標準を策定している標準化団体の略称です ※1。日本語に訳すのは少々難しいのですが、C2PA 創設メンバーの 1 社であるマイクロソフトは「コンテンツの出所と信ぴょう性に関する連合」※2、アドビは「コンテンツ来歴および信頼性のための標準化団体」※3 と表現しています。
この C2PA は、2021 年にアドビ、Arm、インテル、マイクロソフト、Truepic などが中心となって創設され、デジタルコンテンツの生成元や変更履歴を証明できるメタデータを付与することで、ディープフェイクや偽情報の拡散を防ぐ技術の規格(仕様)化を行っています。なお、その普及・推進はアドビが主導する CAI(Content Authenticity Initiative)という団体が担っています ※4。
C2PA に関する大きな動きとして、2023 年 5 月に開催されたマイクロソフトの開発者会議「Microsoft Build 2023」において、Microsoft Designer および Bing Image Creator に C2PA 規格の新しいメディア証明機能を実装する、と発表されたこと ※5 にサイバートラストは注目しました。
これにより C2PA の普及に一層の弾みがつくと感じ、当社は 2023 年 11 月に General メンバーとして C2PA に加入しました ※6。
C2PA には TWG(Technical Working Group)という部会が設置されていて ※7、ほぼ毎日のようにオンラインミーティングが開催され、仕様の検討や技術的課題に関するディスカッションが活発になされています。
2024 年 1 月 25 日に、これまでの C2PA 仕様バージョン 1.4(2023 年 11 月公開)が大幅に改訂されて、2.0 にメジャーバージョンアップされました。
このバージョン 2.0 での概念的な大きな変更点は以下とされています ※8。
This version represents a significant departure from previous versions. It no longer has any references to actors as humans or organizations, they can only be hardware or software entities.
(訳:このバージョンは、以前のバージョンから大きく変わっています。人間や組織としてのアクターへの言及はなくなり、アクターはハードウェアまたはソフトウェアのエンティティのみになる可能性があります。)
アクターとは、Glossary において「A human or non-human (hardware or software) that is participating in the C2PA ecosystem. For example: a camera (capture device), image editing software, cloud service or the person using such tools.」と定義されていて、"A human" の文字はありますが、今後はハードウェアまたはソフトウェアが C2PA 仕様の対象の中心になるものと考えられます。
そしてこの仕様改訂に前後して、ハードウェア・ソフトウェア各社から C2PA 対応に関して以下のような発表が相次いでいます。
また、今年 2024 年は、1 月に実施された台湾の総統選を皮切りに、ロシアやアメリカなど世界の多くの国で大統領選挙や議会選挙が行われる予定で、「選挙イヤー」とも言われています ※14。選挙戦となると、昔から怪情報や偽情報が流布されることがありました(主に紙ビラや口伝など)が、現代では SNS など情報拡散の手段が増えたことと、昨今の生成 AI の急速な進歩・普及により誰もが簡単にフェイク画像やフェイク動画などが作成できてしまう状況となったことが、倫理的・法的・社会的課題(Ethical, Legal and Social Issues、ELSI)として大きく懸念されています。2023 年 10 月 30 日には米国のバイデン大統領が「安全、安心、信頼できる人工知能に関する大統領令」を発行して ※15、生成 AI によるコンテンツの認証とウォーターマーク(電子透かし)によるラベル付与を指示しています。最近は Google も C2PA 運営委員会に参加し ※3、また AI 一般としては AI 悪用阻止協定が締結される ※16 など、コンテンツの出所・信ぴょう性の重要性は増すばかりと考えられます。
先日、OpenAI から画像生成 AI である DALL·E 3 の C2PA 対応を開始したとの発表がありました ※17。
早速、Bing Image Creator(Powered by DALL·E 3)を使用して画像を生成してみたところ、コンテンツの認証情報に「AI で生成」と表示されています。
生成された JPEG ファイルを CAI の Verify サイトで検証してみると以下のように表示され、C2PA の仕様に準拠したコンテンツの来歴情報が含まれていることが確認できます。また、コンテンツ認証情報の発行元は「Microsoft Corporation」になっています。
次に、この JPEG ファイルをバイナリエディタで見ると、実際に C2PA 仕様に従った情報が組み込まれているのが見えます。C2PA 仕様の詳細については、詳しく解説されている記事 ※18 などがあるのでここでは割愛しますが、例えば以下は、その中に含まれる証明書部分となります
証明書の内容を確認すると、サブジェクトの CN(Common Name)と O(Organization Name)が「Microsoft Corporation」になっていることがわかります。
この証明書を発行した上位 CA(中間 CA、ルート CA)の証明書は、証明書の拡張領域に記載されている AIA(Authority Information Access)情報の URL で公開されています。証明書チェーンは以下となり、マイクロソフトのルート CA(Microsoft Supply Chain RSA Root CA 2022)から発行されていることがわかりました。
今後、このような C2PA の署名に用いられるエンドエンティティ証明書やルート CA 証明書に、サイバートラストの証明書も使われるようにしたいと考えています。
「すべてのヒト、モノ、コトに信頼を」
これはサイバートラストの理念でありますが、このような C2PA での取組みもその一環として、安心・安全なデジタル社会の実現に貢献していきます。
以上
参照
これは ABI 互換を保つ上で最も気をつけるべきポイントです。共有ライブラリはその性質上、機能を共通化し、他のアプリケーションから呼び出されることを目的に作られており、そうそう仕様は変わりませんが、時に機能が時代の変化とともに不要になったり、非推奨としなければならない機能が発見されたり、はたまたメンテナンスコストの削減のためコードそのものを削除するなどの理由で、外部向けのインターフェイスである API/ABI にも変更が入ることは年単位で見れば、ままあります。また実験的な実装として不安定なことを予め告知されている機能などは、より良いコードが実装されれば あっさりと切り捨てられる可能性もあります。
ビルド時に用いるコンパイラはバイナリの構造について考えるときに無視できない要素の一つです、過去から現在にいたるまで存在したコンパイラで最も影響力があるのは GNU プロジェクトが開発している GNU Compiler Collection( 以下、GCC) と言っても過言ではないでしょう。そのためシステムコンパイラとしての GCC のバージョンに依存する ABI について解説します。
メジャーなプログラミング言語の一つである、C++ の機能は標準ライブラリ (libstdc++) に依存しており、GCC のバージョンによって非互換なことが公式ドキュメントに記されています。
この記述によると、GCC 3.1.0(2002 年 5 月リリース ), GCC 3.2.0(2002 年 8 月リリース ), GCC 3.4.0(2004 年 4 月リリース ) はそれぞれ、libstdc++ に非互換な ABI 変更が入り、SO(Shared Object) のメジャーバージョンが加算されています。
また Gentoo の wiki には面白いトラブルシューティングが載っています。
この記述によると、GCC 4.1(2006 年 2 月リリース ) や 5.1(2015 年 4 月リリース ) へそれ以前のバージョンから GCC をアップグレードした場合、ABI の問題に直面するため libstdc++ に依存するアプリケーションやライブラリをすべてリビルドする手順を案内しています。
また GCC は ABI の安定性を保証しようとしますが、libstdc++ のすべてがその対象となるわけではなく、例えば C++11(2011 年に発行された C++ の規格の一つです ) の ABI の安定性は GCC 5.1 以降でのみ提供されているということです。
EL9 系の GCC のバージョンは 11 系で、C++14 や C++17( 実験的かつ不完全ですがそれ以降の標準規格も ) をコンパイルすることができます。しかし同じ ( あるいは近似した ) バージョンを使ってビルドしなければ、ABI 互換を完全に保証するのは困難でしょう。
2016 年にリリースされた macOS Sierra では珍しい非互換な変更が行われ、
一部の macOS 向けにビルドされた実行コードの一部が正しく動作しなくなるという問題が起こりました。その原因は gettimeofday(2) というシステムコールの返り値の仕様が変更されたことでした。
標準 C ライブラリのようなラッパーを通したプログラミング言語で書かれたコードは直接の影響はありませんでしたが、例えば Go 言語のように OS が提供するラッパーを通さず、言語側でシステムコールを直接呼び出している言語は 影響を受け 呼び出しを行うコードが修正されました。言い換えれば macOS は Sierra 以前と以後で ABI に非互換性があるとも言えるでしょう。
この記事ではバイナリ /ABI 互換の意味する技術的な側面と周辺情報について紹介をします。AlmaLinux 固有の情報ではなく、他の Linux ディストリビューションを含めた一般論や他の系列の OS も含めた横断的な情報を取り扱います。
Application Binary Interface とは OS( オペレーティングシステム ) の低レイヤに関する技術用語です、狭義には OS とアプリケーションの間の規約を指します、この規約というのは例えばシステム・コールやその呼び出し方法、データの形式やサイズなどのことです。※2ABI は通常 OS やその OS が動作する CPU アーキテクチャによって異なります。例えば 同じ Linux カーネルをベースにした、いわゆる Linux ディストリビューションでも amd64(x86_64) と arm64(aarch64)、powerpc とさまざまな CPU アーキテクチャ向けにソフトウェアがビルドされます。一般にアーキテクチャが異なればコンパイルされたオブジェクトコード ※3 は他のプラットフォーム向けには互換性を持たないため動作しません。同様に異なる OS に対してもオブジェクトコードは互換性を持ちません。※4 なぜならシステム・コールの呼び出し規約やデータ構造は OS によって異なるためです。
また Linux ディストリビューションによっても、ディストリビューションに含む共有ライブラリのバージョンが通例的には異なるため、ディストリビューション間での共有ライブラリの ABI 互換は保証されません。
特別な配慮 ( すべてのライブラリを静的リンクするなど ) などを行わない限り、例えば RHEL 向けにビルドした実行コードは Ubuntu では動かないとみなすべきですし、安全のためにはディストリビューションごとに個別にビルドするのが望ましいでしょう。
ABI 互換性がある、と述べられた場合、ある OS/ アーキテクチャ向けにビルドされたオブジェクトコードがそのシステムでも動作することを指し、互換性が壊されないように注意深く構築されているという意味合いを持ちます。
バイナリの持つ ABI をユーザーが自分で調べることも可能です、いくつか調査を行うために必要になる情報を出力してくれるツールを紹介します。
ある実行ファイルが実行時にどんな共有ライブラリをロードするかを調べる標準的なツールとして、 'ldd(1)' が知られています。
$ ldd $(which ssh) linux-vdso.so.1 (0x00007ffd66516000) libcrypto.so.3 => /lib64/libcrypto.so.3 (0x00007fd837abf000) libz.so.1 => /lib64/libz.so.1 (0x00007fd837aa5000) libcrypt.so.2 => /lib64/libcrypt.so.2 (0x00007fd837a6b000) libselinux.so.1 => /lib64/libselinux.so.1 (0x00007fd837a3e000) libgssapi_krb5.so.2 => /lib64/libgssapi_krb5.so.2 (0x00007fd8379e7000) libc.so.6 => /lib64/libc.so.6 (0x00007fd8377de000) libpcre2-8.so.0 => /lib64/libpcre2-8.so.0 (0x00007fd837742000) /lib64/ld-linux-x86-64.so.2 (0x00007fd837fc4000) libkrb5.so.3 => /lib64/libkrb5.so.3 (0x00007fd837664000) libk5crypto.so.3 => /lib64/libk5crypto.so.3 (0x00007fd83764b000) libcom_err.so.2 => /lib64/libcom_err.so.2 (0x00007fd837644000) libkrb5support.so.0 => /lib64/libkrb5support.so.0 (0x00007fd837633000) libkeyutils.so.1 => /lib64/libkeyutils.so.1 (0x00007fd83762a000) libresolv.so.2 => /lib64/libresolv.so.2 (0x00007fd837616000)
この実行結果は ssh コマンドを実行したときにロードされている共有ライブラリのリストを表しています。
標準的な慣習として共有ライブラリの ABI 互換性が維持される間は同じバージョン番号を使用し、非互換を伴う変更が入った時にバージョンが変更 ( 大抵の場合はメジャーバージョンを 1 つ加算する ) し、SONAME が変わるようにします。
上の例からバージョンを読み取ると、例えば libc.so.6 は メジャーバージョンが 6 であることを示しています。※5
readelf は ELF 形式の実行ファイルの情報を表示するツールです。
$ readelf --dynamic $(which ssh) Dynamic section at offset 0xc00c0 contains 33 entries: Tag Type Name/Value 0x0000000000000001 (NEEDED) Shared library: [libselinux.so.1] 0x0000000000000001 (NEEDED) Shared library: [libcrypto.so.1.1] 0x0000000000000001 (NEEDED) Shared library: [libdl.so.2] 0x0000000000000001 (NEEDED) Shared library: [libz.so.1] 0x0000000000000001 (NEEDED) Shared library: [libresolv.so.2] 0x0000000000000001 (NEEDED) Shared library: [libgssapi_krb5.so.2] 0x0000000000000001 (NEEDED) Shared library: [libc.so.6] [...]
-d オプション ( 又は --dynamic オプション ) をつけることで Dynamic section を表示してくれます。 この Dynamic section には依存する共有ライブラリの情報が埋め込まれています。
abidiff はその名前のとおり、共有ライブラリの ABI の diff を表示してくれるツールです。共有ライブラリのパスを指定して使います。
以下の例では 2 つのバージョンの OpenSSL 共有ライブラリを比較しています、
CentOS 7 向けにビルドされたパッケージに含まれる SO(Shared Object) ファイルと CentOS Stream 8 向けにビルドされた SO ファイルを比較対象としています。( この 2 つのバイナリはマイナーバージョンが異なるため、リリース当時の OpenSSL プロジェクトのポリシー ※6 では API/ABI に変更が入っていてもおかしくありません、また意図的にメジャーバージョンの異なるディストリビューションのバイナリをサンプルとしてピックアップしています )
$ abidiff --d1 c7/rootfs --d2 cs8/rootfs c7/rootfs/usr/lib64/libssl.so.1.0.2k cs8/rootfs/usr/lib64/libssl.so.1.1.1k ELF SONAME changed Functions changes summary: 0 Removed, 0 Changed, 218 Added functions Variables changes summary: 0 Removed, 0 Changed, 0 Added variable Function symbols changes summary: 587 Removed, 0 Added function symbols not referenced by debug info Variable symbols changes summary: 12 Removed, 0 Added variable symbols not referenced by debug info SONAME changed from 'libssl.so.10' to 'libssl.so.1.1' 218 Added functions: [...] $ echo $? 12
サマリーを見ると 218 個の関数が追加され、587 個の関数名のシンボル、12 個の変数名のシンボルが除去されていることがわかります。シンボルが除去されている場合、共有ライブラリをリンクしている実行コードから呼び出す関数へジャンプする際に名前解決ができずにエラーで終了するでしょう。
( とはいえ実際にはほとんどのケースではコードを実行する前に OS が共有ライブラリのバージョンとファイル名が異なるためロードに失敗し、実行そのものが差し止められるでしょう )
また SONAME が 'libssl.so.10' to 'libssl.so.1.1' に変化しています。バージョン名が変更されていることを含めて考えると、OpenSSL の 1.0.2k と 1.1.1k の間には ABI 互換性が無くなっていると考えていいでしょう。
この推測を abidiff の結果で裏付けてみましょう、実行例ではコマンドの終了ステータス ( シェル変数 : $?) として 12 が返ってきています。
abidiff を 開発している libabigail プロジェクトのマニュアルによると、第 3 ビット (2 進数で 4) と第 4 ビット (2 進数で 8) が立っている場合、ABI の非互換な変更が検知されたことを意味しています。
ABI をわざわざ調べなくても常識的ではありますが、OpenSSL を動的リンクしているアプリケーションで CentOS 7 向けにビルドしたバイナリは CentOS Stream 8 では動作しないということがわかります。 ( 逆もまた然りです )
多くの OS では ABI の安定性は限られたコンポーネント、さらにメジャーバージョンの範囲でのみ維持されるのが標準的で、OS のメジャーバージョンが異なれば少なくともリビルドしなければ動かないと考えたほうがいいでしょう。
ABI 変更が検知されなかった場合は、特に出力もなくコマンドは終了します。これを確かめてみるには比較してみたいバイナリファイルを用意し、 abidiff に渡してみると ABI 互換性が保たれていることを確認できます。異なるディストリビューションに対して行ってみると興味深い ( あるいは退屈な ) 結果が得られるでしょう。
History
From release 1.0.0, but prior to release 3.0.0, the OpenSSL versioning scheme was different and it is detailed here for historic purposes.
・Letter releases, such as 1.0.2a, exclusively contain bug and security fixes and no new features.
・Releases that change the final number, e.g. 1.1.0 vs. 1.1.1, can and are likely to contain new features, but in a way that does not break binary compatibility. This means that an application compiled and dynamically linked with 1.1.0 does not need to be recompiled when the shared library is updated to 1.1.1.
・Releases that change the second number, e.g. 1.0.0 vs 1.1.0, break both ABI and API compatibility. The primary instance of this was the transition to opaque internal structures that occurred with OpenSSL release 1.1.0.
https://www.openssl.org/policies/general/versioning-policy.html
AlmaLinux は RHEL との ABI 互換を持つディストリビューションを構築するという方向にプロジェクトの方針を転換しました。目標が後退しているかのように見えますが、変わらないことがあります。それは RHEL で動くソフトウェアをそのまま問題なく動作させるという目的が依然として含まれていることです。
多くのユーザーはあらゆる側面で RHEL と同じ OS を使いたいわけではなく ( あらゆる側面で同じ物はそれ自身しか存在しません )、既存のソフトウェアやノウハウを再利用できれば充分であると考えられ、ABI 互換であればこのニーズを満たすことができます。
ポリシーの変更により、可能になることもあります、ABI 互換性を崩さない範囲であれば、アップストリームによる判断を待たずにバグ修正を行ったり、取り入れる変更についてアップストリームとは別のアプローチを試みることも許容されます。このような目的のために release-testing というリポジトリがすでに用意されています。
アップストリームとの違いを持つことにより、CentOS Stream のような上流のプロジェクトと協力をすることができるようになります。
そして AlmaLinux が自ら独自に行う変更は ABI 互換を壊さない範囲に限定されるでしょう、つまり互換性を破壊してしまうようなバージョンアップ、修正パッチのバックポート、独自パッチの追加、ビルド方法の変更などは行われないということを意味しています。
1:1 互換にこだわることなく、ABI 互換に舵を切ったことにより、ほとんどのユーザーのニーズを満たしながらも、アップストリームの意向を尊重し、エンタープライズ Linux を構築しているエコシステムの良き市民として活動するという姿勢を打ち出しています。
また単に RHEL で動くコードがそのまま動く無償のディストリビューションという選択肢を提供するだけでなく、ダウンストリームとして独自の違いを持つことも可能になり、CentOS Stream のような上流のプロジェクトと協力することも可能になりました。この方針がエコシステムの今後の活性化に繋がることを願っています。
「ID」とは、そのデータやもの、ユーザーを特定するための一意性がある識別情報のことです。
「ID」の例としては、インターネット上のサービスや社内システムへアクセスするための「ユーザー ID・パスワード」などがあります。
例えば、社内システムへアクセスするための「ID」である「ユーザー ID・パスワード」が攻撃者に窃取されてしまった場合は、その「ID」を使用して正規のユーザーになりすまし、その組織の内部システムや機密データに不正アクセスが可能となるため、機密情報や個人情報が外部に漏洩してしまうことになります。
この「ID」を標的とした攻撃のことを指して、「ID」ベースの攻撃と呼んでいます。
「ID」ベースの攻撃は、以下のようなものが挙げられます。
ID 中心のセキュリティ戦略に関する教育と情報を発信している非営利団体の IDSA(Identity Defined Security Alliance) の発表したレポート「IDSA 2023 Trends in Identity Security」において、1000 人以上を抱える組織における IT セキュリティ とアイデンティティに深い見識を持つ 529 名の個人に対して行われた調査によると、「ID」の多様化が進む背景として以下のような要因が挙げられています。
また、「ID」の多様化によりユーザーが使用する「ID」も増加するため、「ID」を標的とする「ID」ベースの攻撃も増加します。
実際、当ブログの「QR コードを悪用したフィッシングメールに要注意!」や「 ドメイン名ハイジャックによるドメイン名の乗っ取りに注意 」でもご紹介したとおり、2023 年 10 月、フィッシング対策協議会が公表した フィッシング報告状況 によると、過去最多となる 156,804 件となりました。
(出典)フィッシング対策協議会「2023/12 フィッシング報告状況 」
加えて、IDSA の調査報告によると、実際に組織が受けた攻撃の中で最も多かったのは「フィッシング(Phishing)」が 62%で1位であり、2 位の「クレデンシャルスタッフィング」などを含む「ブルートフォース攻撃(総当たり攻撃)」の 31%と比較しても、フィッシング攻撃が群を抜いて 1 位となっています。
(出典)IDSA のレポート「IDSA 2023 Trends in Identity Security」
そして、このフィッシング攻撃の経路としては、「メールによるフィッシング」が 93%と最も多く、さらにユーザー起因の ID 関連のインシデントについても、「フィッシングメールを受け取ったユーザーによるクリック」が発生原因となっているものが 57% と最も多い状況となっています。
もし、窃取された「ID」の悪用による情報漏洩のようなインシデントが発生したとしたら、インシデントからのリカバリのコストがかかり、業務へにも支障が発生し、会社へのネガティブな評価による悪影響もあるため、「ID」ベースの攻撃への対策、とりわけフィッシングに対する対策は急いで行う必要があります。
では、この増加する「ID」ベースの攻撃、特にフィッシングの対策はどのようにしたらよいでしょうか。
これらの対策としては 多要素認証(MFA) が有効かつ重要です。
「ID」以外のほかの要素による認証も行うことで「ID」が漏洩したとしても、別の要素の認証に失敗するため、インシデントを未然に防ぐ、あるいはインシデントの被害を最小化することが可能です。
また、多要素認証(MFA) の設定には様々な認証方法の選択肢があるため、ID/ パスワード以外のユーザーの負担が少ない認証方法の組み合わせを選択することで、ユーザーの利便性向上が期待できます。
なお、冒頭でもご紹介した フィッシング攻撃「AiTM」 にように、SMS や認証アプリなどの他の要素による認証を回避する攻撃も存在するため、多要素認証(MFA)を導入される際には「フィッシング耐性」が高い「証明書ベースの認証」を選択することが有効です。
「 サイバートラスト デバイス ID」は、 デバイス識別情報を遠隔で確認 した上で管理者が許可したデバイスに登録します。
厳格なデバイス認証を実施してクライアント証明書をデバイスに登録することで、本人が所持しているという情報に加えて、" どの " デバイスからのアクセスを許可するかも制限可能です。
つまり、アクセスを許可していないユーザーはもとより、アクセスを許可しているユーザーであっても、そのユーザーによるデバイスの私的利用や持ち込みを防ぐことが可能となります。
また、クライアント証明書を所持していれば、クライアント認証に対応している複数のサービス・システムの認証要素として使用可能なため、ユーザーの利便性向上が期待できます。
多要素認証(MFA)の導入を検討いただく際には、ぜひ認証要素の 1 つとして、「サイバートラスト デバイス ID」の導入もご検討いただけますと幸いです。
「使用感を実際に体験してみたい」、「既存の環境で運用できるか検証したい」などのご要望の際は、是非とも 無償トライアル を通じてデバイス ID をお試しください。
インターネット上で標準的に利用される暗号通信プロトコルである SSL および TLS の機能を実装した OpenSSL(オープン・エスエスエル)は、提供されるバージョンによってサポート期限があります。BLOG:FIPS 140-3 に準拠した OpenSSL の最新バージョン「OpenSSL 3.1」公開 でも解説しています。2023 年 11 月に最新バージョンであります「OpenSSL 3.2.0」が公開されており、次期バージョンであります「OpenSSL 3.3.0」が、2024 年 4 月までに公開予定であることを OpenSSL Project が公表しています。
さらに、サーバー証明書の有効期間は、業界規制やブラウザーの仕様変更によって、2024 年 2 月現在の最長の有効期間は 1 年となっています。
サーバー運営者は、技術動向、業界規制や主要ブラウザーの仕様変更など、さまざまな業界動向を理解し、サーバー運用しなくてはなりません。そして、複数のサーバーを運用するサーバー運営者にとっては、サーバー証明書の申請、取得、インストールなどの管理負荷は大きなものではないでしょうか。
サイバートラストでは、各種サーバーの CSR 作成 / 証明書インストール手順書 をはじめ、サーバー証明書の管理負担を軽減するために、SureHandsOn ACME を提供しています。SureHandsOn(シュアハンズオン)は、SSL/TLS サーバー証明書「SureServer」のお客様の企業情報を年に一度でまとめて審査を行うことで、サーバー証明書の発行のたびに本来なら生じる電話確認や書類審査などの諸手続きを省くことができ、24 時間 365 日(サービスメンテナンス時を除く)、お客様による申請・発行を可能にしたマネージドサービスです。年間に 10 枚以上のサーバー証明書をご利用のお客様で、申請処理(申請、電話応対等)の手間の軽減、ならびに発行のタイミングをお客様自身でコントロールしたいとお考えの場合、ご利用いただくと大変便利なサービスで、費用ならびに運用面でメリットがあります。枚数に応じた割引価格が適用されるなどのコストメリットがあります。
SureHandsOn ACME は、国際標準の ACME プロトコルを用いた証明書管理の自動プログラムで、お客様のサーバーに初期設定後、サーバー証明書の申請、取得を自動化でき、サーバー証明書の更新漏れを防ぎ管理コストを軽減することができます。
SureHandsOn ACME は、無償にて提供しており、お客様のサーバーに ACME クライアントを設定いただくことで利用可能で、以下のサーバー環境においてサーバー証明書更新を自動化することが可能です。
IIS および Azure 環境におけるサーバー証明書更新を自動化する場合は、ACME クライアント「win-acme」が動作する環境を介して、取得したサーバー証明書と秘密鍵をアップロードすることができます。
(IIS の発行申請例)
(Azure の発行申請例)
ACME(Automated Certificate Management Environment の略)
ウェブサーバーと認証局との間の相互作用を自動化するための通信プロトコル で、利用者のウェブサーバーにおいてサーバー証明書の自動展開を可能とするもので、RFC8555 として公開されています。
前述しました BIG-IP、IIS や Azure 環境における更新自動化および SureHandsOn ACME の詳しい内容については、是非 お問い合わせください。
]]>前編 ~ イランのハッカーがイスラエルのテクノロジー企業にマルウェア攻撃を開始 ~ はこちら
2023 年 10 月 10 日に、Citrix Netscaler ADC/Gateway の脆弱性 (CVE-2023-4966) が公開されました。こちらの脆弱性は、公開されるとすぐに悪用が観測され、有名な LockBit ランサムウェアグループや Medusa ランサムウェアグループによっても悪用されました。
これを受けて、CISA/FBI が LockBit グループによる「Citrix Bleed(CVE-2023-4966)」脆弱性悪用について注意喚起も行っています。
以下では、脆弱性「Citrix Bleed」を悪用した攻撃に関する情報を纏めます。
項目 | 内容 |
---|---|
Who(誰が) | LockBit ランサムウェアグループ/Medusa ランサムウェアグループ |
When(いつ) | 2023 年 10 月 10 日 |
Where(どこで) | JAXA |
What(何を) | 内部ネットワークに不正アクセス |
Why(なぜ) | スパイ・諜報活動の一環と思われる。 |
How(どのように) | 不明 |
2023 年 12 月時点で、Citrix Bleed を悪用しているランサムウェアグループとして
の2つが挙げられています。以下で、それぞれのランサムウェアグループに関する概要をまとめています。
LockBit ランサムウェアグループは 2019 年に出現し、それ以来重大な脅威をもたらしている脅威アクターです。LockBit は、その RaaS (Ransomware-as-a-Service)モデルで広く知られており、二重恐喝を専門としています。
2022 年、LockBit は世界中で最も多く導入されたランサムウェアの亜種であり、2023 年も引き続き Top の座をキープしています。
LockBit を使用するアフィリエイト(攻撃の実行者)は
等を攻撃の対象としてきました。
LockBit では、Ransomware-as-a-Service (RaaS) モデルとして
を提供しており、実際のランサムウェア攻撃を実行するアフィリエイターが募集されています。
アフィリエイトが多数存在するため、LockBit ランサムウェア攻撃では都度観察される戦術、技術、および手順 (TTP) が大きく異なっています。この点がランサムウェアからシステムを保護しようとしている組織にとっては非常に課題となっています。
Medusa ランサムウェアグループは 2021 年 6 月に観測され、セキュリティ専門家の注目を集めている脅威アクターです。Medusa も、最近の脅威アクターと同じく RaaS (Ransomware-as-a-Service)モデルで広く知られています。
Medusa は、Medusa Blog を通じて被害者を発表して二重脅迫を行い、連絡先情報としてメールとテレグラムを併用しています。被害者のお知らせをクリックすると、カウントダウンタイマーが開く様になっています。
Medusa は攻撃の大部分が北米とヨーロッパに集中しており、その標的もランダムではなく、2023 年のミネアポリス学区をターゲットにしたように、教育機関に集中して国際社会への波紋を確実にもたらすような戦略が取られています。
<参考情報>
2023/11/2 | LockBit ランサムウェアグループにより、ボーイング社への攻撃が行われる。 |
---|---|
2023/11/9 | LockBit ランサムウェアグループにより、中国工商銀行への攻撃が行われる。 |
2023/11/16 | Medusa ランサムウェアグループにより、Toyota Financial Service への攻撃が行われる。 |
<参考情報>
現時点で確定しているのは
だけですが、他にもニュースになっていない被害者がいると考えられます。
製造、金融サービスの内部ネットワークに不正アクセスし情報を入手。その他に、食品、農業、教育、エネルギー、政府関連機関、医療、輸送等がターゲットとして考えられます。
LockBit ランサムウェアグループ/Medusa ランサムウェアグループの両方とも、金銭目的のランサムウェアグループとして活動しているため、目的は純粋に恐喝による身代金が目的と思われます。
以下、CISA が公開している LockBit ランサムウェアグループ(ボーイング社のインシデントを実例に書かれている)に基づいて説明します。
●CVE-2023-4966
●CVE-2023-4967
この脆弱性の悪用が 2023年8 月下旬から実際に行われていることを Mandiant 社が確認しています。悪用に成功すると、既存の認証されたセッションがハイジャックされる可能性があり、その結果、多要素認証 (MFA) やその他の強力な認証要件がバイパスされる可能性があります。
ボーイング社のインシデントから、LockBit3.0 アフィリエイトが CVE-2023-4966 を悪用して Boeing Distribution Inc. への初期アクセスを取得していることが観察されました。
前述の Citrix Bleed を悪用することで、攻撃者はパスワードと多要素認証 (MFA) をバイパスして、NetScaler ADC および NetScaler Gateway 上の正規ユーザーに対するセッションハイジャックが成功します。
攻撃者は、正規のユーザーセッションを乗っ取ることによって資格情報を収集し、水平移動(ラテラル・ムーブメント)を行い、データやリソースにアクセスするための、より強い権限レベルのアクセスを取得していました。
以下に MITRE ATT&CK の表を示します。
- ATT&CK Techniques for Enterprise: 発見(Discovery)
Technique | Title ID | 使用 |
---|---|---|
システム情報の発見 | T1082 | 脅威アクターは、バージョンやパッチなど、OS やハードウェアに関する情報を入手しようとします。 |
- ATT&CK Techniques for Enterprise: クレデンシャルアクセス(Credential Access)
Technique | Title ID | 使用 |
---|---|---|
認証プロセスの変更:多要素認証 | T1556.006 | 脅威アクターは、バージョンやパッチなど、OS やハードウェアに関する情報を入手しようとします。 |
Web セッションクッキーの窃取 | T1539 | 有効な Cookie にアクセスできる攻撃者は、ユーザー名/パスワード/多要素認証 (MFA) トークンへのアクセスを必要とせずに、NetScaler アプライアンスで認証済みセッションを確立できます。 |
IoC に関しては、分量が多いので、本記事では割愛させていただきます。CISA の出している「StopRansomware: LockBit 3.0 Ransomware Affiliates Exploit CVE 2023-4966 Citrix Bleed Vulnerability」を確認してください。
<参考情報>
2023 年 11-12 月の脅威動向を見るために、以下で発生したインシデント・攻撃を羅列します。
1. マルウェア・ランサムウエア攻撃
2. 国際関係に起因するインシデント・攻撃
3. その他のインシデント・攻撃
OSS/ セキュリティ / 脅威インテリジェンスエバンジェリスト
面 和毅
一層の多様化・巧妙化が進んでいるサイバー攻撃に対し、医療機関内の閉域環境下であっても従来の外部との通信制限を行う境界型防御では対策が不十分であるとし、BLOG:いまさら聞けない「ゼロトラスト」とは? でも解説していますように「ゼロトラスト」の概念がシステム運用編に追加されています。
(出典)厚生労働省「医療情報システムの安全管理に関するガイドライン 第 6.0 版 (システム運用編)」
これまで、内部不正やシャドー IT により発生していたセキュリティインシデントに加え、近年では医療機関で発生した VPN 装置の脆弱性を悪用し、ランサムウェア攻撃によって電子カルテシステムが長期間停止する事態が発生しています。このことから、ゼロトラストの概念にもとづき、医療情報システムにアクセスできる利用者やコンピュータの正当性を確認する仕組みの構築が必要とされています。
「医療情報システムの安全管理に関するガイドライン 第 6.0 版 (システム運用編)」のネットワークに関する安全管理措置の遵守事項において、SSL-VPN を利用する場合に、クライアント証明書を用いたクライアント認証が必須であると明記されています。
なお、クライアント認証については、BLOG:クライアント認証とは? で詳しく解説しています。
(出典)厚生労働省「 医療情報システムの安全管理に関するガイドライン 第 6.0 版 (システム運用編)」
VPN 接続を行う際、クライアント証明書がインストールされているパソコンなどの端末のみがアクセスできるようにし、反対にクライアント証明書がインストールされていない端末のアクセスを防ぐことができるため、VPN 装置の脆弱性を悪用するサイバー攻撃や、シャドー IT 対策として有効な手段となります。
「医療情報システムの安全管理に関するガイドライン 第 6.0 版 (システム運用編)」の利用者認証において、二要素認証技術の端末などへの導入を 2027 年度時点で稼働している医療情報システムに採用する必要性について明記されています。なお、二要素認証(多要素認証)については、BLOG:多要素認証(MFA)とは? で詳しく解説しています。
(出典)厚生労働省「医療情報システムの安全管理に関するガイドライン 第 6.0 版 (システム運用編)」
ただし、現在では二要素認証を回避する AiTM 攻撃 という手法が存在するため、米国政府※ならび Microsoft 社ではフィッシング耐性のある FIDO 認証もしくは電子証明書ベースの認証が有効であるという見解を述べています。
※ 米国土安全保障省(DHS)のサイバーセキュリティ・インフラストラクチャセキュリティ庁
最適な医療を実現するための基盤整備を推進すべく、政府は医療 DX 推進本部を 2022 年に設置しました。その中の一つとして電子カルテや電子処方箋の電子データを共通基盤のクラウドで管理し、各医療機関ならびに自治体や介護事業者などとも必要な情報が共有できる「全国医療情報プラットフォーム」を構築する予定となっており、今後ますます医療機関などにおける医療情報システムへの認証は重要となります。
(出典)厚生労働省「 医療 DX(その 1)」
サイバートラストでは、サイバー攻撃に有効な証明書ベースの認証を可能にする「 サイバートラスト デバイス ID」を提供しています。「サイバートラスト デバイス ID」は、 端末識別情報(MAC アドレス、IMEI、UDID、シリアル番号、Wi-Fi Mac)を遠隔で確認 した上で管理者が許可した端末に登録します。
そのため、端末識別情報の特定に関する細かなアクセスポリシーの設定を行えないようなご利用環境であっても、厳格な端末認証を実施してクライアント証明書を端末に登録することで、よりセキュアにクライアント認証をご利用いただけます。
デバイス証明書をエクスポート出来ない状態で登録 を行うため、管理者が意図していない管理外の端末で証明書を使われないようにすることが可能です。
「サイバートラスト デバイス ID」は、初期費用なし、10 ライセンスからご利用可能で、WEB 申し込みから 10 営業日以内の短期間で導入可能です。
なお、「サイバートラスト デバイス ID」では、 無償で 1 ヶ月間、10 台までの機器で評価いただけるトライアルキット をご提供しております。「使用感を実際に体験してみたい」、「既存の環境で運用できるか検証したい」などのご要望に、是非ともトライアルを通じてデバイス ID をお試しください。
また、サイバートラストでは、デバイス ID を利用した医療情報システムへのアクセス権限の堅牢化の他に「医療情報システムの安全管理に関するガイドライン」へ適合した「 サイバートラスト 医療 DX ソリューション 」を提供しておりますので、何か課題やお困り事があれば是非ともお問い合わせください。
2021 年 10 月 31 日、院内システムがランサムウェアに感染し、電子カルテが閲覧できなくなるなどの大きな被害に見舞われたことを受け、院内ネットワークへのリモートアクセスにおけるセキュリティ強化を目指し、クライアント証明書サービスの「サイバートラスト デバイス ID」を採用いただきました。