Linuxのセキュリティ:ご質問にお答えします
by Canonical on 30 March 2023
Canonicalでは、Linuxのセキュリティはもちろん、オープンソースのセキュリティについて質問をいただくことがよくあります。当社セキュリティチームが開催した先頃のウェビナーと対応のブログ投稿に基づき、よくある質問と回答をまとめました。すべてのご質問にお答えすることはできませんが、セキュリティの脆弱性の管理、ライブパッチ、IoT、コンプライアンス、堅牢化ツールに関するUbuntuの取り組みを一般的にご紹介します。
Linuxのセキュリティについてさらに知りたい、または他の質問をお持ちの方は、https://ubuntu.com/security/contact-usまでお問い合わせください。
Ubuntuとセキュリティの脆弱性の管理
デスクトップで処理できれば、ESM(Expanded Security Maintenance)でも20.04.5 LTSを安全に使用できますか?20.04が本当に気に入っているからです!
はい、もちろん安全です。Ubuntu ProのESMはすべてのUbuntuパッケージに10年間のセキュリティメンテナンスを提供します。個人利用の場合は機器5台まで無料です。詳細は、https://ubuntu.com/proをご覧ください。
Ubuntuの各リリースには何件のCVEが統合されていますか?
セキュリティの脆弱性(CVE)に対するパッチ提供はリリースのサポートが終了するまで継続します。Canonicalは、リリースされたすべてのセキュリティ修正の詳細を含むOVALデータをUbuntuのウェブサイトで公開しています:https://ubuntu.com/security/oval
たとえば、最新の22.04(Jammy)LTSリリースのOVALデータによると、本記事執筆時点では、2022年4月にJammyがリリースされて以来、249件のCVEが公開されています。
以前、私のUnix OS Internalsの教授は、多くのシステム管理者がパッチやアップグレードをすぐには適用しないと話していました。パッチに想定外のバグが含まれていることがあるためです。
それは時代遅れです。業界の統計によれば、ほぼすべてのハッキングやシステム侵害は、パッチが提供されていたにもかかわらずシステムに適用しなかったために発生しています。今日では、システム侵害のリスクはシステムが不安定になることのリスクをはるかに上回っています。
システムの安定性を維持するため、システム管理者がsnapパッケージの自動更新をオフにすることを許可する計画はありますか?
自動更新をオフにすることはお勧めしません。先ほど説明したように、システムの侵害はパッチが適用されていない既知の脆弱性を攻撃者が悪用したときに発生するからです。snapを安心して使用したいのであれば、安定性を損なわない重要なセキュリティ更新のみ受け取ることも可能です。
オープンソースソフトウェアとLinuxのセキュリティ
Linuxのオープンソースの性質によって脆弱性が増えることはありますか?
簡単に言えばいいえ。まったくありません。この件については、Ubuntu Security Podcastのエピソード185で詳しく説明しています(登録は不要です)。Buteも今後の投稿でこのトピックを扱う予定です。ブログのニュースレターを購読してポッドキャストをお聞きください。
Ubuntuは基盤となるDebianよりも安全ですか?
UbuntuのセキュリティをDebianと直接比較することはできません。UbuntuはDebianパッケージをベースとしますが、Debianのエコシステムにないソフトウェアパッケージも数多く含みます。Canonicalは、Ubuntu Proによってこれらのパッケージのフルセキュリティメンテナンスを10年間提供します。
Ubuntuのセキュリティ、コンプライアンス、堅牢化
Ubuntu ProのCISベンチマークコンプライアンスツールのレポート機能と堅牢化機能について説明してください。
Ubuntu Proでは、オペレーティングシステムをCISベンチマークの基準に合わせて堅牢化するツールを利用できます。また、システム堅牢化について知っておくべきことをまとめた新しいガイドをリリースしました。こちらをご覧ください。
再起動時にPINを手動で入力せず、TPMに直接紐付けてハードドライブ暗号化を使用するネイティブな方法はありますか?
非常に良いご指摘です。この問題については現在検討中です。
Ubuntuのバージョン22.04に対応するUbuntu Security Guideはありますか?
現在作成中であり、2023年4月末までに公開予定です。
改変不可、エフェメラル(一時的)、Infrastructure as Code(コードとしてのインフラストラクチャ)の時代に、なぜまだパッチや再起動の話をしているのですか?自動化を導入し、インフラストラクチャを「世話」すべきものとして扱うのをやめるべきではないでしょうか?
確かに業界はその方向に進んでいますが、ここまで議論してきたセキュリティの基本はコンテナやIaCにも当てはまります。ソフトウェアにはパッチを適用する必要があり、脆弱性が見つかったときにはコンテナを更新する必要があります。
インフラストラクチャをデプロイする方法(手動または自動)で、コンポーネントのセキュリティの必要性が変わるわけではありません。また、改変不可のコンテナに関しては、古いソフトウェアが何年間も実行されるリスクが高まります。ソフトウェアがコンテナで実行されている場合でも、パッチを適用し、更新されたコンテナをデプロイする必要があります。
ライブパッチ:カーネルの実行中にパッチを適用
カーネルのパッチ適用プロセスに貢献するコミュニティには簡単に参加できますか?特定の地域に拠点を置く必要がありますか?
インターネットの世界では誰でも協力することができるので、特別に世界のどこかに拠点を置く必要はありません。https://discourse.ubuntu.com/からUbuntuコミュニティにご参加ください。
Canonicalではライブパッチをどのようにテストしますか?
カーネルへのライブパッチ適用は繊細なエンジニアリング作業です。不完全なライブパッチがマシンに影響を与えるリスクを最小限に抑えるため、ライブパッチのテストとデプロイは段階的に行います。
- CanonicalがLinuxカーネルの高い脆弱性または重大な脆弱性を検出すると、社内のカーネルエンジニアが脆弱性に対処するためのライブパッチを作成します。
- ライブパッチは、最初にCanonicalの社内サーバーファームでテストされます。
- その後、次の順序で段階的に導入します。
- 社内でのデプロイ
- 無料サブスクリプションユーザー
- 顧客
- 特定の段階で不完全なライブパッチが検出された場合は、当然、他のマシンへの適用を停止します。
ライブパッチをオンプレミスでデプロイすることを選択した顧客は、この段階をさらに詳細に設定できます。ライブパッチをすべてのマシンに一度に適用するのではなく、少しずつ段階的に適用するのです。つまり、ライブパッチサーバーを必要な数の階層で構成できます。このコンテキストでは、階層をパッチが配置されるコンテナとして定義できます。
その後、マシン/ライブパッチクライアントのインスタンスを特定の階層にマッピングできます。サーバーには、エッジ、ベータ、候補、安定のデフォルトの階層リストがあります。このリストはライブパッチ管理ツールを使用して変更できます。
本番環境で欠陥のあるライブパッチを適用し、問題が発生したことはありますか?
入念にテストしても、欠陥のあるライブパッチが適用されるリスクは常にあります。たとえば2021年、Ubuntu 16.04 LTS(Xenial)のカーネル4.4にあった深刻度がMedium(中)のCVE(CVE-2020-29372)に対処するためのライブパッチです。
社内のテストでライブパッチの不良が検出されなかったのは、欠陥がワークロード固有の動作によって引き起こされるレースコンディションだったためです。このライブパッチはmadviseシステムコールを無期限にブロックし、コールを使用するプロセスをロックアップします。これらの状況はテスト環境で再現されませんでした。
不良ライブパッチがテストに合格したのは、新しくプロビジョニングしたシステムだけでテストしたためです。問題を起こすロックが別の状態にあるプロセスを持つシステムを実行しなければ、ロックアップに到達する条件は発生しませんでした。
詳細はこちらをお読みください:https://canonical.com/blog/livepatch-2021-03-24-incident-investigation-report
ライブパッチが不良だった場合、どのように回復しますか?
不良から回復する方法は複数あります。いずれにしても、再起動後に不良ライブパッチが再び適用されないよう、ライブパッチサービスを一時的に無効にします。
システムが稼働中の場合:
- ライブパッチを無効化
- snap stop –disable canonical-livepatch
- 以下のコマンドを発行して、問題のあるライブパッチを削除:
- sudo rm -rf /var/snap/canonical-livepatch/common/payload
- 再起動
カーネルコマンドラインにしかアクセスできない場合
- 以下を追加し、カーネルコマンドラインからライブパッチサービスをオフにする:
- systemd.mask=snap.canonical-livepatch.canonical-livepatchd.service
- 以下を発行し、問題のあるライブパッチを削除:
- sudo rm -rf /var/snap/canonical-livepatch/common/payload
- 再起動
grub2ブートメニューにしかアクセスできない場合
- バックアップカーネルを選択して起動
- ライブパッチクライアントが失敗したパッチを削除し、バックアップカーネルの最新のライブパッチを取得
IoT
Canonicalには、IoTの管理、パッチ、デプロイに関連するサービスがありますか?どのようなオプションがありますか?
Ubuntu Coreがここでの解決策です。Ubuntu CoreはIoTやデバイス向けのUbuntuであり、すべてsnapで構築されています。snapとは、コンテナ化し、制約を設け、デフォルトでセキュリティを確保したソフトウェアランタイム/デプロイメカニズムであり、最新のセキュリティ修正を自動的に反映します。Ubuntu Coreのセキュリティの詳細はこちらをご覧ください:https://assets.ubuntu.com/v1/66fcd858-canonical-ubuntu-core-security-2018-11-13.pdf
詳細は、Ubuntuのセキュリティとサンドボックスの基本、当社の組み込みLinuxに関するホワイトペーパー:YoctoとUbuntu Core、および組み込みLinuxの構築と購入に関する記事をご覧ください。
その他
コンピューターのセキュリティは今後10年間で私たちの生活にどのような影響を及ぼしますか?
未来のことははっきりとはわかりません。しかし、確実に言えるのは、Ubuntu Proを利用すれば、個人利用の場合は最大5台の機器に対して無料で10年間のセキュリティメンテナンスを受けられることです!
複雑な取り付けが不要なiCloud、OneDrive、Googleドライブのような「組み込み」マルチデバイスクラウドドライブはいつ登場するのでしょうか?登場すればUXは向上し、ストレージの安全性も高くなるでしょう。
未来のことはわかりませんが、数年前に展開を試みたUbuntu Oneストレージは成功しませんでした。したがって改善策はありますが、すぐに新しいバージョンをリリースすることはないでしょう。
結び
UbuntuまたはLinuxのセキュリティに関してさらに不明な点がある場合は、https://ubuntu.com/security/contact-usまでお問い合わせください。
Canonicalは、Linuxのセキュリティ関連の新しいコンテンツを定期的に公開しています。ご登録いただければブログの更新情報を随時お届けします。
ニュースレターのサインアップ
関連記事
コンフィデンシャル、一般提供、オープンソースとは? それがMicrosoft Azure対応Canonical Ubuntu 22.04!
Canonicalの全チームを代表し、Microsoft AzureでUbuntu 22.04 Confidential VM(CVM)の一般提供を発表いたします!今回のCVMは、第3世代のAMD CPUに追加されたセキュリティ拡張機能Secure Encrypted Virtualization-Secure Nested Paging(SEV-SNP)に対応するMicrosoft Azure DCasv5/ECasv5シリーズの一環です。 したがってUbuntu 22.04 CVMは、クラウドの特権システムソフトウェア(ハイパーバイザ、ホストOS、ファームウェア)を侵害しかねない強力な敵、あるいはVMに不正にアクセスできる悪質な、または侵害を受けたクラウドプロバイダ […]
UbuntuでAzureのクラウドセキュリティを強化
セキュリティを重視した環境の基盤を構築 大半の組織は現在、多少なりともクラウドを運用し、その攻撃対象領域は急速に拡大しています。中小企業から大企業まで、セキュリティを重視する組織には、安心してクラウドワークロード(特に規制の厳しい、機密性の高いもの)の保護を任せられるオペレーティングシステムが必要です。 Ubuntuは、開発と運用の両面で世界で最も人気の高いオープンソースオペレーティングシステムです。その汎用性、信頼性、常に更新される機能、幅広い開発者向けライブラリにより、世界中の多くの開発チームに信頼されています。このオペレーティングシステムを支えるのがCanonicalです。 セキュリティはUbuntuの最優先事項です。Azure Marketplaceで自由に使える […]
パブリッククラウドでのコンフィデンシャルコンピューティング: 隔離とリモート認証について
このブログシリーズの前半では、実行時のセキュリティ問題について扱いました。コードやデータは、パブリッククラウドのインフラストラクチャに含まれる特権システムソフトウェアやその管理者に対して脆弱なのです。この問題に対処する方法として、TEE(trusted execution environment、信頼できる実行環境)とコンフィデンシャルコンピューティング(CC)の概念についても紹介しました。CCの考え方は現実的です。まず、クラウドのシステムソフトウェアがブートストラップする実行環境を信用できないものと見なし、セキュリティ重視のワークロードは隔離されたTEEで実行することを提案します。TEEのセキュリティ保証の根拠は、プラットフォームの最も基本的なハードウェア層にあります。 […]