AWS - 不正利用事例の確認と考え方

AWSはAzureと比べてインターネット上に情報が沢山存在する。市場シェアが高く、ユーザが多いためである。そのため、このサイトではよくあるEC2の立て方、使い方といった内容を説明するのではなく、現場がより欲している内容について説明する。

AWS不正アクセス事例

まず、AWSを利用したいという人に私が一番最初に説明する二つの事例を参考引用する。

参考引用：AWSが不正利用され300万円の請求が届いてから免除までの一部始終

参考引用：初心者がAWSでミスって不正利用されて$6,000請求、泣きそうになったお話。

こういったＡＷＳの不正アクセスや不正利用は、世の中で実際に発生している。彼らの技術力が足りなかったとは言わない。新しい仕組みを利用する場合には、こういったインシデントはつきものだ。

AWSの対応も素晴らしいものがあった。しかし、それはAWSの善意であったことも忘れてはいけない。必ず不正請求が返ってくるわけではないことを頭に入れておこう。

これら事例以外にも、s3に顧客情報を置いておいたら、そのs3バケットはパブリック公開だった。といった企業のインシデントも世の中では多々発生している。

どうすれば防げたのか

これら不正利用は、アクセス権を持つキーやユーザを公開してしまったことが原因である。それを防ぐには、アクセス権を公開しないということが第一と、万が一アクセスされても、アクセス元を制限することやアクセスされてもリソース作成権限は付与していないといった権限制御をしておく。といったような対策が考えられる。確かに、面倒ではあるが、こういった基本に沿った対策の積み重ねが自らを救うのである。

最後の「開発環境もAWSとしては商用環境であることを認識する」についてだが、問題が発生するのは開発環境である場合が多い。商用環境はしっかりセキュリティ対策を行っていたが、開発環境は商用環境と同じ対策を実施していなかった。というインシデントが多い。

商用環境、開発環境の定義はユーザ側で実施しているに過ぎない。AWS側はどちらも商用環境であり、利用料は請求する。開発環境でも、しっかりとセキュリティ設計、安全対策は実施しよう。

それでもAWS利用することが怖いと思う方へ

それでも、AWSは怖い、クラウド利用は怖いという方は、利用を見送るのも手だろう。無理にクラウドを使うことはない。

しかし、それはパソコンなんて信用ならないと言っていた時代と変わらない。選択のリスク、ビジネス変化についていけないというより大きなリスクも認識すべきである。

次回は、個別のセキュリティ対策について説明する。