ITmedia NEWS
業界動向
「入れたら動いた、めでたしめでたし」とはならない、クラウドセキュリティの課題

「入れたら動いた、めでたしめでたし」とはならない、クラウドセキュリティの課題（1/2 ページ）

公開 2020年04月03日 09時53分

更新 2020年04月01日 08時34分

[ITmedia]

印刷する

　変化するニーズに素早く対応し、新しいサービスを迅速にリリースしたくても、オンプレミスで環境を調達・設定するのに時間がかかって足を引っ張ってしまう――。そんな状況を変え、デジタルトランスフォーメーション（DX）を実現しようと考える企業の間で、新規サービスはもちろん、基幹システムもクラウドへの移行が進んできた。

　だがセキュリティ企業のラックによると、それに伴って、クラウドのセキュリティに関する相談もまた増加傾向にあるという。

　一般的には、クラウドよりもオンプレミス環境の方が安全だと考えられがちだ。だが実は、インフラからアプリケーションまでの全てを自らの責任で運用しなければならないオンプレミス環境に比べ、事業者と利用企業の間で責任を分け合うクラウド環境のほうが、デフォルトならばセキュアな状態にあるという。では一体何が問題なのか。ラックの「サイバー救急センターレポート第8号」をまとめたメンバーに尋ねた。

ラックが発行した「サイバー救急センターレポート第8号」。クラウドサービスにおけるインシデントの発生状況や脅威情報などがまとめられている

設定変更時のミスが侵害の元に

　ラックの初田淳一氏（セキュリティプロフェッショナルサービス統括部コンサルティングサービス部担当部長）によると、ランサムウェアや「Emotet」のようなマルウェア感染や、不正アクセスに関する相談は依然として多いという。だがそれ以上に目立つのが「サーバに対する不正侵入、特にクラウドでのインシデント対応の相談の増加だ。クラウド環境はデフォルトでセキュアに設定されているが、管理や設置の不備が原因となり、侵害を受けてしまうことが多い」という。

　「Amazon Web Services」（AWS）や「Microsoft Azure」といったクラウド基盤は、自分たちで一から環境を構築する場合に比べ、物理的なファシリティからハードウェアなどの対策が施されている上、デフォルト設定もセキュリティが考慮されている。

ラックの初田淳一氏（セキュリティプロフェッショナルサービス統括部コンサルティングサービス部担当部長）

　にもかかわらずインシデントが起きている理由として、同社サイバー救急センター長の鷲尾浩之氏は「オンプレミスからクラウドにシステムを移行する際に、なるべくそのままの構成で移行しようとし、『例外的に変更しよう』『やむなくこうしておこう』と（イレギュラーな対応で）変更したところが狙われている」と解説した。

　実際に起こったあるインシデント事例では、クラウド上に構築したテスト環境が侵入を受けてマルウェアに感染していたことに気付かず、そのまま本番環境に移行してしまったそうだ。「デフォルト設定は強固だったにもかかわらず、テスト用に弱いパスワードに変更してしまった上、テスト目的でいろいろ不要なアプリケーションや脆弱性が残っている環境をそのまま使ってしまったのではないか」（初田氏）。ファイアウォールに守られたオンプレミス環境の感覚がどこかに残ったまま、公開を前提としたクラウド環境に移行してしまったことも一因かもしれないという。

アクセスキーの管理にも留意すべき

　もう1つ、クラウド環境の侵害の原因となっている大きなポイントが「アクセスキー」だ。AWS環境ではユーザーアカウントの他に、APIなどのリソースにアクセスする際にアクセスキーが求められるが、この管理が不十分なケースが目立つという。

　別の事例では、複数の開発者が共有していたアクセスキーの流出が原因となり、勝手に多数のインスタンスを起動されて仮想通貨のマイニングに利用されてしまった。高額の請求が届いてはじめて侵害に気づいたという。

　同社サイバー救急センターの尼子雄大氏は、「残念ながら、アクセスキーを認証情報と認識しておらず、適切に管理していないケースが少なくない。そんなに大事な情報だとは思わずに、サンプルプログラムなどに埋め込んで公開リポジトリ上で公開してしまう事例もある」と指摘する。

　一方で、攻撃者がAWSのアクセスキーをスキャンしていると思しきトラフィックは継続的に観測されており、2019年8月中旬にはスパイク的な増加が発生した。「本来ならば公開されるべきでないアクセスキー情報が何らかのミスや不備で公開されているという、クラウドのセキュリティの問題を攻撃者側は認識しており、悪用するために日常的に探しているのではないか」と初田氏は指摘した。

　もちろん、クラウド環境においても、オンプレミスと同様に認証情報の管理が重要だという意識は高まっており、アカウント情報の使い回しをやめたり、多要素認証を導入して認証を強化する動きが広がっている。これに対し、アクセスキーについてはそこまで意識が至っておらず、その性質上、多要素認証で保護するのも難しい。時には「『アクセスキーって何ですか』と顧客に聞かれることもある」（尼子氏）ほどだ。まずはそのリスクに気付くことが安全性を高めるポイントだという。

　1つの対策案として、万一アカウント情報やアクセスキーが悪用されたとしても、早期に気付けるようなモニタリング体制を整えることが考えられる。また可能であれば、ペネトレーションテストを実施して、不必要なアカウントやアクセスキーが露出していないかをチェックすることも助けになるという。

次ページへ「入れたら動いた、めでたしめでたし」はNG