多様なサイバー脅威が蔓延る中、富士ソフトのソリューション事業本部内で有志を募り、セキュリティ座談会を実施。その座談会の様子を連載形式でお届けします。
Part２では、“ログを取得するだけでは不十分”という観点から、ログ活用フローの重要性について議論しました。Part３では視点を変え、シングルクラウドとマルチクラウド、それぞれのメリット・注意点をセキュリティの観点から掘り下げます。
参加メンバー
北村 明彦
ソリューション事業本部 インフラ事業部
川西 就
ソリューション事業本部 インフラ事業部 クラウドソリューション部
脇屋 徳尚
ソリューション事業本部 インフラ事業部
岩品 慶子
ソリューション事業本部 インフラ事業部 インフライノベーション部
櫻井 秀憲
ソリューション事業本部 インフラ事業部
シングルクラウドのメリットは“分かりやすい”こと
―企業がサイバー攻撃の被害に遭った場合、従業員はパニックに陥っていることも多く、“即座に状況を分析するのは難しい”とされています。この問題について、ご意見をお聞かせください。
北村：シングルクラウド環境であれば、管理する環境の数が少ない分、状況把握や対応が比較的スムーズに行えるケースもあります。もちろん100%ではありませんが、たとえばAWS環境のみであれば、Amazon GuardDuty（AWSアカウントやワークロードなどの脅威を検出できるサービス）を導入するだけで脅威が検出され、すぐに対策を講じることができます。
一方、マルチクラウドの場合、どこから侵入してきたか、どのような状態にあるか、全容を把握するのは時間もコストもかかります。
脇屋：企業では、“会社全体ではお抱えのクラウドベンダーAを使っているが、 事業部ではクラウドベンダーBを使っている”といったケースがよくあります。その場合、コミュニケーションロスが生まれ、対処の優先順位も付けづらくなります。よりパニックに陥りやすく、対応のハードルが上がるのです。
――“マルチクラウド活用”を謳う現代から逆行しているようにも思えます。
北村：シングルクラウドの方が「安全性が高い」とは言えませんが、「分かりやすい」のは確かです。マルチクラウドと比較すると、どこから脅威が侵入してきたかが分かりやすいのです。
岩品：ただし、“分かりやすいからシングルクラウドを選ぶべき”というわけではありません。選択肢に絶対的な正解はなく、自社の体制やスキルに応じて、無理のない構成を選ぶことが大切です。
ハブ構成やAI活用が効果的
――マルチクラウドの場合、具体的にどのような点に気を付けるべきでしょうか。
北村：各クラウドベンダーが提供するツールは、基本的には自社のクラウドを守ることを前提に作られています。外部からの接続を「信頼していい」と判断するのは人間です。
AWSで言えば、AWS内で交わされる通信は最初からある程度守られる設計になっています。一方、外部からの接続を、「別のAクラウドから通信が届いている。Aクラウドなら接続しても問題ない」と、“過去に接続して問題がなかった”、あるいは“名前を知っている有名クラウドだから”などの理由だけで安易に信頼してしまうのは問題です。
それぞれのクラウド単体では強固に守られていても、境界部分でトラスト設定を甘くしてしまうケースが多く、マルチクラウドのセキュリティリスクを招く要因の1つになっています。
――“どこから来た通信をトラストするか”は、どのように判断するべきでしょうか？
北村：基本的には、他のクラウドや管理領域から来る通信は、一旦すべてブロックするべきだと思います。何が来てもまずはブロックして、確認してから許可するというゼロトラスト（すべて信用せずに検証することを前提とした概念）の考え方です。
それぞれの通信をもれなく確認することで、セキュリティレベルを向上できます。「○○から来た通信は信頼していいですか？」と聞かれたら、YESではなくて「要確認です」と答えるのが基本姿勢です。
――セキュリティが担保される一方で、利便性が失われる可能性もありそうです。全体を効率的に確認・管理できるようなツールはあるのでしょうか。
川西：一括で管理したいのであれば、各クラウドのAPIを統合して、横断的に管理・可視化できる“クラウドセキュリティ統合基盤” のようなサービスの利用を検討すべきです。たとえば、Prisma CloudやMicrosoft Defender for Cloudなどが該当します。
SASE（Secure Access Service Edge：ネットワークとセキュリティをクラウド一体で提供する仕組み、および概念）の構成をとり、こうした統合基盤を中央に配置することで、“まずそこを通して通信を精査する”というアプローチが可能になります。通信のルールやポリシーを一元化することで、全体の統制が取りやすくなるのです。
櫻井：今は機械学習を活用したAIにより“普段と違う接続”などのリスクを検知してくれる仕組みも活用されています。たとえば、あるユーザーによるアクセスが、物理的に距離の離れた2拠点から短時間であった場合など、“違和感のある”ケースを学習して自動で検知してくれるのです。アラートがあればSOC（Security Operation Center：企業の情報システムを監視する専門組織）のアナリストなどが確認し、必要に応じてエスカレーションして対応します。
北村：ただ、ハブ構成やAIを活用したサービス利用は、コストが増大します。そもそもマルチクラウドは各クラウドのいいとこ取りができるメリットはありますが、構成自体にコストがかかります。
岩品：セキュリティの観点だけを見て、同じデータを複数のクラウドに置いているケースもあります。保存や同期するたびに、倍のコストがかかる点には注意しなければなりません。特に、仮想マシン環境はマシンイメージをそのまま移行できると考えて増やしてしまうケースも多く見られます。
北村：実際にはクラウドごとに実装が微妙に異なるため、完全に同じようには動かない点に注意が必要です。
結局は1から構成を考え直すことになり、想像以上のコストが発生することもあります。
川西：マルチクラウドを活用する場合、“ログの量”も意識しておく必要があります。とにかく膨大な量で、アラートも次から次へと出てくるため、1件ずつ誤検知か否かを人間が見ている暇はありません。しかも、製品ごとに誤検知の判断基準が異なります。その課題を解決するために、統合的に管理してくれる基盤やAIを活用することは手段の1つですが、コストと天秤にかける必要があります。
注意すべきは“放置アカウント”
――他にも気を付けるべき点があれば教えてください。
北村：マルチクラウドの場合は、予算があればSSO（シングルサインオン：一度の認証で複数のサービスにログインできる仕組み）を積極的に活用していただきたいです。実際、大企業のクラウド移行案件では、SSOを含めて認証を強固にしたいという要望が多いです。
セキュリティにおいて、意外と忘れがちなのが、検証環境で一時的に利用したアカウントや退職者のアカウントの無効化・消去です。ID1つを無効化するだけで、すべてのクラウドからのアクセスを遮断できるSSOは、マルチクラウドセキュリティにおいて有効です。
櫻井：攻撃者が侵入してまず狙うのが、使われていないグループやアカウントです。使っていないのに放置されている管理アカウントなどからゲストユーザーを作られると、新たな侵入口になってしまいます。そのため、SSOを導入できない場合でも、定期的にアカウントの棚卸しを実施することをおすすめします。
川西：導入当初の“誰も覚えていない強力な権限を持ったアカウント”が見つかることも、実はよくあります。
北村： APIキーなどの管理も重要です。同じクラウド内ならIAM（Identity and Access Management）ロールなどで権限を制御できますが、クラウドをまたぐとキーの使用は避けられない場合があります。その場合、キーの権限が強すぎたり管理が甘かったりすると、攻撃者に狙われる可能性が高まります。インスタンスを作れたり壊せたりする強い権限が付いていると、重要な基盤が破壊される最悪の事態になりかねません。
北村：また、まれに“スーパーマン”のように複数のクラウドに精通する人もいますが、一般的には一人のエンジニアが得意とするクラウドは1、2種類程度です。
先ほど「クラウドごとに微妙に実装が異なる」と述べた通り、マルチクラウド構成を組む際に、あるクラウドでの前提や感覚をそのまま他のクラウドに当てはめて設計してしまうと、思わぬ抜け漏れが生じる可能性があります。こうしたリスクを避けるためにも、各クラウドの仕様に精通した専門家を適切に関与させることが重要です。
関連記事について
前の記事はこちら
『セキュリティ座談会 Part２｜【未取得のリスク】なぜ“ログは取るべき”なのか』
記事一覧はこちら
セキュリティ座談会に関する記事一覧
関連サービスについて、詳しくはこちらをご覧ください。
