クラウド内のAPIセキュリティ

クラウド関連のセキュリティは、AWS、Microsoft Azure、Google Cloudなどのクラウド・プラットフォームやサービスを提供する会社が責任を持って処理してくれると思っているIT管理者は少なくありません。クラウド内でどのくらいビジネス・トランザクションが起こっているかを考えると、それが危険な思い込みだとわかります。

残念ながら、これらのWebサービスのセキュリティが限定的であることを知って愕然とする人たちがかなりいます。クラウド・サービスを購入しても、実際には共有API内のITセキュリティは共通の責任です。

Brad Geesaman 氏は、このような勘違いをしている人をたくさん見てきました。氏は、Symantec、Blackfin などで仕事をし、ITセキュリティとインフラストラクチャの分野で15年以上の経験を持っています。善意のハッカーとして、ネットワークに対するセキュリティ脅威から身を守る手法を教示してきました。Geesaman 氏は、現在は、私的なITセキュリティコンサルティングを行っています。

ラスベガスで開催された Black Hat USA カンファレンスでの Geesaman 氏の講演を聞いて、すぐにイプスイッチのポッドキャストに招待したいと思ったのですが、このたび、Defrag This ポッドキャストへの出演依頼に応じていただくことができました。Geesaman 氏に、共有クラウド・プラットフォームで使われる資産をしっかり保護するにはどうすればいいかについて話していただきました。

Geesaman 氏へのインタビューの概要を以下に記述します。氏が Black Hat で行った講演のスライドは、こちらからアクセスできます。

思い込み：クラウドプロバイダが共有APIセキュリティ問題に対処する

AWS（または Google Cloud、Microsoft Azure などの他のクラウドプラットフォーム）を使用している企業が、クラウドプロバイダがセキュリティに責任をもってくれると考えるのは、よくある誤解です。

IT管理者は、クラウドサービスが転送データの安全性を保証していると思い込んで、これらのセキュリティ領域を見過ごしがちです。この思い込みは、単に間違いです。共有APIのセキュリティは共通の責任です。

正しい認識：共有APIセキュリティ責任の境界線はあいまい

AWSは、利用者の責任が何であり、AWSの責任が何であるかについて、一見すると明確なように見える責任範囲の図を作成しています。ですが、実際には、責任範囲の境界線はかなりあいまいです。

両方の当事者にとって、顧客もクラウドサービスも単なるAPIエンドポイントです。顧客はAPIへのキーを持っており、Webサービスはアクセスが有効であることを確認する責任があります。単純なことのように見えますが、キーを持っている人は誰でもアクセスできるという明白なことが忘れられがちです。

Geesaman 氏は、15年以上にわたる経験の中で、キーが危険にさらされているのを何度も見てきました。洗練されたボットネットによって、あるいは、サポートチケットにアカウント番号を書いてポストするセキュリティ意識が低い人によって。こういったことで、企業のクラウドデータは大きな影響を受けることになります。

脅威はどこから？

AWS（または他のクラウドプラットフォーム）に対する脅威は数多くあります。Geesaman 氏が考える、クラウド利用において脅威となり得るセキュリティ問題の発生源には次のものがあります。

• 開発者 - オペレーションの開発者が、ターゲットになりやすいセキュリティ保護されていないラップトップを使用していることがよくあります。
• サード・パーティーのサービス - APIキーを必要とするサード・パーティーのサービスがターゲットになることもあります。アカウントに統合された電子メール・クライアントや、そのほか、ソフトウェアとの接点があるサービスには、すべてリスクが伴います。
• 暗号化マイニング - 暗号化マイニングには高いレベルの処理パワーが必要なので、悪意あるハッカーは、他の誰かのクラウドプラットフォームに簡単にアクセスできる方法を探し、そのCPUを使おうとします。クラウドサービスから高額の請求書を受け取って初めて乗っ取られていたことに気が付きます。
• ボットネット - ネットワーク全体に散在するハッカーは、デフォルトのテストパスワード（Abcd1234など）を利用するボットを使用します。これらのボットは、簡単なパスワードなら数分で破ってネットワークにアクセスします。
• 未公開の脅威 - 本当に恐ろしい、悪意があって大きな被害を及ぼす脅威は、聞いたことがないものかもしれません。誰も、侵入された方法を正確に公表することは好まないでしょう。最も洗練された攻撃は、未公開かもしれず、公表されたとしても他社が自身を守るのに役立たないような情報しか得られない可能性があります。

プロテクトするにはどうすればいいか？

Geesaman 氏は、IT管理者が組織をプロテクトするためにはどうすればいいか、思考プロセスを提案しています。

1. 「これが破られて侵入されたら、ハッカーは次に何にアクセスできるか」と問う通常のITセキュリティモデルから始めてください。これを繰り返してエンドポイントに達したら、そのエンドポイントから後ろ向きに考察します。
2. それぞれの段階で、攻撃を制限してネットワークを保護するために必要なツールを検討してください。答えが見つからない場合、ネイティブシステムに解決策がない場合は、ベンダーの使用を考えるべきでしょう。

まとめ

要約すると、Geesaman 氏が強調するのは、組織のデータと資産を保護するのはIT管理者の仕事だということです。ネイティブサービスはソリューションの多くを提供するかもしれませんが、ネットワーク全体のセキュリティを保証してはくれません。

共有APIの責任は共有されます。