はじめに
みなさま、こんにちは。ユーザ・リレーションズ・チーム（以下UR）の冨田です。
2024/7/1、OpenSSHの脆弱性に関するニュースが発表されました。
当社ではお客様のデータを保護するために、1日以内に対策を実施・完了しました。
結論から書くと、fusion_place cloudやFMCをはじめ、お客様のデータに関わるサービスのOSは当脆弱性の影響範囲外でした。
社内利用目的のUbuntuサーバー1台が影響の対象であったためOpenSSHのセキュリティ対応済バージョンへの更新を実施しました。
本記事では、対応までの流れや良かった点、および今後の課題についてご紹介します。
弊社サービスのユーザー様や、企業のインフラ・セキュリティ担当の方々の感想やご意見をいただけると幸いです。
対応までの流れ
対応の流れは以下の通りです。
- 脆弱性のニュースを確認
- 影響範囲の確認。社内利用のサーバー1台を特定
- 情報共有。SREチームに報告
- 当該サーバーの業務担当者にOS再起動による業務への影響がない事を確認
- SREチームによりOpenSSHの更新を実施
- 対策完了の報告
良かった点①情報収集の習慣化
セキュリティ情報の定期的な収集を行う事により、SNSやWebブラウザのおすすめにこういったニュースが表示されやすくなります。
今回もSNSで関連のニュースが弊社メンバーの目に止まった事が迅速な対応につながりました。
良かった点②Slackによる社内連絡体制
日頃よりSlackを活用した社内連絡が浸透していることが、対応を円滑に進めるための重要な要素となりました。
今回、情報共有から対策完了の報告までの連絡はSlackの1つのスレッドで完結しています。
良かった点③日頃のセキュリティ意識
弊社ではISO27001/27017に基づくISMSを運用している他、週次で行われる開発会議においても外部のインシデント事例や現状の改善点などについて共有が行われています。
このような活動によって、リスクに気づいたら早めに声をあげる文化が醸成されています。
今後の課題①情報収集漏れをいかに防ぐか
情報収集漏れを防ぐためには、さらに情報収集の体制を強化する必要があります。例えば専任チームの設置や、外部セキュリティサービスの活用などが考えられます。
今後の課題②工数のかかる根本対策
今回はそもそも影響範囲が少なかったため最低限の対応時間ですみましたが、大きなリスクを未然に防ぐ根本的な対策も必要です。例えばSession Managerの活用によりSSHを使用しない事も選択肢となります。
こういった根本的な対策には工数がかかるため、効率的なリソース配分と優先順位の設定が求められます。長期的な計画を立て、持続的なセキュリティ強化を目指したいと考えております。
参考サイト
piyokango様のブログ記事が当脆弱性の概要や対策について非常によくまとまっており、調査にかかる時間が大幅に短縮されました。
この場を借りて御礼を申し上げます。
