クラウド普及で事故激増ーースクリプト化したスピード攻撃が、ラフな権限管理を狙い撃ち

イエラエセキュリティの顧問を務める川口洋が、多彩なメンバーと共にサイバーセキュリティやサイバーリスクの今を語り合う座談会シリーズ。今回はイエラエセキュリティでクラウド診断を担当する白木光達と共に、クラスメソッド株式会社よりセキュリティチームのリーダーとして活躍する臼田佳祐氏をお招きし、クラウドセキュリティについて存分に語り合います。

イエラエセキュリティは2021年3月18日、AWS, Azure, GCP, Salesforceを対象とした「クラウド診断」サービスの提供を開始（プレスリリース：イエラエセキュリティ、AWS, Azure, GCP, Salesforceを対象とした「クラウド診断」サービスの提供を開始）。パブリッククラウド上に構築されたサービスの安全性についてセキュリティエンジニアが評価を行う脆弱性診断を行うことで、お客様のクラウド利用環境の安全性確保に貢献します。

更にイエラエセキュリティは、2019年よりアライアンスを結んできたクラスメソッド株式会社と共に、AWS総合支援サービス「クラスメソッドメンバーズ」加入企業に向け、「クラウド診断」と「対策サポート」を提供するオプションサービスをスタートさせました。（プレスリリース：クラウドセキュリティの死角となる認証認可などの設定ミスを解消。診断・対策サポートを提供開始）

本サービススタートをきっかけに、クラウドセキュリティやインシデントに日々対峙するメンバーに、会社という枠組みを超えて、お集まりいただくことが出来ました。クラウドネイティブな環境における“今”のリアルな状況を、顧問・川口洋が詳しく聞きます。どうぞお楽しみください！

 

クラウド環境におけるセキュリティ意識の高まりを受け、新メニュースタート

川口洋（以下、川口）：イエラエセキュリティ顧問の川口洋です。今日は、クラウドセキュリティのアレやコレやについて、クラスメソッドの臼田さんとイエラエセキュリティの白木さんにご登場頂き、お聞きしていきたいと思います。

白木さんには、本座談会シリーズに度々ご登場頂いていますが（ハードウェアとソフトウェア、セキュリティの交わるところ）、クラウドセキュリティの話に特化して伺うのは初めてかもしれませんね。

白木光達（以下、白木）：イエラエセキュリティの白木光達と申します。もともとモバイルアプリのセキュリティ診断や、IoT、Webの診断等を担当していましたが、最近は主にクラウド診断に従事しています。昨年度まではSECCONの実行委員として活動したりもしていました。また保有資格として、各社クラウドベンダーのものを持っています。最近、Azure Solution Architects Expertも取得しました。

 

 

川口：すごい数持っていますね！　GIAC、AWS、GCP、Azure、Salesforce...総舐めしてるじゃないですか。

白木：クラウドの診断を提供していくにあたって、どうしても、各種クラウドベンダーのベストプラクティスを深く理解する必要があって、その過程で取得しました。もちろんセキュリティの知識だけでも診断できる部分はあるんですが、やはりクラウドベンダーの考える設計のベストプラクティスから理解していないと、設定変更に終始するような局所最適なセキュリティ対策を提案してしまったりするので・・・。

川口：今年3月にイエラエセキュリティが発表した「クラウドセキュリティ診断」サービスは、白木さんの資格が総動員している感じで、AWS、Azure、GCPを中心とした各種クラウドベンダーに幅広く対応していますよね。

白木：はい。AWS, Azure ,GCPの3大クラウドに対応しており、サービスラインナップは、IaaSベースのアプリケーションを対象とした「クラウド診断」、サーバーレス構成を取っているアプリケーションを対象にした「クラウド診断 サーバーレス」、あとはコンテナベースのアプリケーションを対象にした「クラウド診断 コンテナ」この3種類です。

あともう一つ、最近よく話題になるセールスフォースについて診断する「クラウド診断セールスフォース」も提供しています。セールスフォースでは、複雑なアクセス権の管理が必要になってきますので、社内で見直す際にもし不安がありましたら、ご相談頂ければ問題抽出のお手伝いが出来るかと思います。

 

 

川口：サーバーレスやコンテナなどの利用形態もメニューになるくらい、クラウドの利用方法は多様になってきているんですね。

白木：従来のようなクラウドの使い方も勿論多いですが、サーバーレスやコンテナでの利用もかなり広がっていますね。従来の診断とはまた別の観点が必要になってきますので、別のメニューに分け、フォーカスする部分を変えて提供させて頂いております。

川口：このメニューをクラスメソッドのAWS総合支援サービスにも展開することになったのを受け、今日はクラスメソッドの臼田さんにも来て頂いています。クラスメソッドの登場は、執行役員の佐々木さんに引き続き2人目ですね（クラウド時代のセキュリティ対策とはーー “セキュリティ”と“AWS”のプロがタッグを組んで実現する未来像）。臼田さん、自己紹介よろしくお願いします。

臼田佳祐（以下、臼田）：クラスメソッドの臼田佳祐です。弊社はクラウドベンダーとして、非常に沢山のお客様とやり取りさせて頂いています。最近ですと、「AWSコンサルティングパートナーオブザイヤー2020」という賞を頂きました。AWSの、日本でトップのコンサルティングパートナーに贈られるもので、2018年から2度目の受賞です。ご支援させて頂いたお客様の数や、内容についてご評価頂いていると思っています。

 

私自身は、AWS事業本部でシニアソリューションアーキテクトとして、AWS環境の構築やコンサルティング等、様々なアドバイスをする仕事をしています。また、部署を横断して動く“セキュリティチーム”のリーダーをしています。AWSのセキュリティ系サービスや、AWSに利用できるサードパーティのセキュリティ系製品を検証するのが業務内容です。

弊社技術ブログ「DevelopersIO」に、AWSに関するブログ記事を沢山書いています。 また、AWSの公認インストラクターとして、AWSが提供している各種トレーニングで講師を務めたり、数あるAWSユーザーグループの中で「Security-JAWS」という支部の運営をしています。

好きなAWSのサービスは“Amazon Detective”で、AWS上で起きた様々なインシデントの調査をするためのサービスです。2020年3月末にリリースされたんですが、めちゃくちゃ良く出来ていて、私は非常に好きなサービスです。

川口：クラスメソッドの方は、自己紹介で必ず、好きなAWSのサービスを言いますよね。

臼田：AWS界隈では「このサービスが好きです」という自己紹介をする習慣があるんです。初対面でも、話をする良いきっかけになるんですよ。

川口：白木さんの、好きなAWSのサービスはなんですか？

白木：“AWS Security Hub”や“Amazon GuardDuty”といったところでしょうか。やはり一番触る機会があるサービスですので。

クラウド普及により頻発する「アクセスキーの漏洩」事故

川口：最初に、クラウド環境でどんな問題が起きているのか、状況を知りたいんです。よく問題になっているケース、よく相談をもらうケースについて、臼田さんからご紹介頂けますか。

臼田：AWS上で一番多い事故と言って過言ではないのは、IAM（Identity and Access Management：アイアム）、つまりアクセスキーの漏洩です。もともと問題としてはずっと起こってきていることですが、ここ最近は特に事故が増えていますね。

川口：非常に基本的なことのように思えますが……実際に、事故は沢山起きているわけですね。これを“やってしまう”パターンに、傾向はありますか。慣れている方がついやってしまうのか、新しくクラウドを使い始めたビギナーがしくじりやすいのか。

臼田：クラウドを使うのが当たり前の時代になってきたことで、いわゆる“マジョリティ”の方たちがAWSを始めとしたクラウドを使い始められていて、ユーザーの母数が非常に増えてきています。そのような方達の中に、“クラウド”という概念をしっかり理解されず、アクセスキーをラフに使ってしまっている方が多い印象です。

以前からクラウド環境を利用して使っている企業内でも、これまでは限られた担当者のみがクラウドに触っていたので特に問題がなかった、というケースも多いです。社内での利用者層が広がるにつれ「AWSってこういう使い方をしなければいけないんだよ」というトレーニングや、ガバナンスを効かせる仕組みが必要ですが、それが追いついてないように思えます。

川口：白木さん、診断の中で、アクセスキー漏洩を見つけることはありますか。

白木：イエラエセキュリティの「クラウド診断」に興味を持って頂くようなお客様は、ある程度クラウド利用について理解されておられることが多いので、診断中に見つけたことは無いですね。ただ、弊社フォレンジックチームでは、そのようなアクセスキー漏洩と思わしき侵害についてご相談を頂くことは結構あります。

川口：なるほど。ここで臼田さんに是非、伺いたいんですが……アクセスキーって、そんなにみんな、作って、使うものなんですか。

臼田：（笑）

川口：いや、もちろん、分かるんですよ、エンジニアはアクセスキーを作って便利にしたい。分かる、分かりますけど……。事故ってしまうレベルの人が、ホイホイとアクセスキーを作って、何か、やってしまうものなんですか。

 

 

臼田：まさに、アクセスキーの重要性や正しい使い方を理解されていない状態で使われてしまうことが多く、それが事故に繋がっていると思います。一番典型的な事故パターンは、開発者がアクセスキーを作成して、それをアプリケーションコードに埋め込み、更にそのアプリケーションコードが、GitHubに上がっているという……

※ なおAWS CloudShell等の機能を利用することで、アクセスキーを発行せずにCLIからAWSリソースを操作することも可能です。アクセスキー漏洩リスクの低減のためアクセスキーを発行しない運用についてもご検討ください。（ご参考：待望の新サービス AWS CloudShell がリリースされました！ #reinvent）

川口：ああ……。

臼田：これら“重ね技”によって、パブリックな場所に大切なアクセスキーが公開されるという事故が頻発しています。そもそも、業務で作ったアプリケーションコードが、パブリックなGitHubにプッシュされているのは大きな問題ですよね。AWSをはじめとしたクラウドの使い方以前の、コードの管理等についても徹底して頂く必要があります。

川口：クラウド環境の利用が増えてきていると同時に、GitHubに慣れていない人が使ってしまうということも増えてきているのかもしれませんね。

臼田：我々は開発者の方に「git-secrets」というツールを必ず入れて頂くように推奨しています。誤ってアクセスキーを埋め込んだまま、gitのリポジトリ等に公開してしまうことを、水際で防ぐための方法のひとつですね。そういったツールもまだまだ、普及してないという状態です。

川口：「git-secretsは使っているけど、これで十分なのか、時々不安になる」という方に向けて、「ここもう一歩踏み込んでほしい」ということを教えて欲しいです。

臼田：最近ですと、SSRFの脆弱性を突いた攻撃が見られます。その場合には、単純なIAMユーザーのアクセスキーの窃取ではなくて、AWS環境のEC2の上で動いているwebアプリケーションの、 EC2に割り当てられたIAMの認証情報が窃取されるという手法です。限定的なケースではありますが、少し設定が緩かったり、アプリケーションの脆弱性など、要因が重なると起きてしまう事例ですので、警戒して貰えればと思います。

アクセスキー漏洩から10分以内で、不正マイニング開始

臼田：実際にアクセスキーが漏洩した時にどういったことが起こるのか、被害にあった環境をベースにまとめた記事がDevelopersIOにありますので、ご紹介します。2年前の記事ですが、攻撃が非常に高度化しているのが分かるような記事の内容になっています。

【実録】アクセスキー流出、攻撃者のとった行動とその対策

弊社メンバーズをご利用のお客様は、PowerUser権限のアクセスキーを利用し開発を実施していました。その作業中に誤ってPublicなGitHubリポジトリにアクセスキーをPushしてしまったのが事の発端になります。その後アクセスキーが何者かに不正利用され仮想通貨のマイニングが行われました。最終的に流出したキー経由で作成されたリソースを全て削除する事で事態は収束しています。（記事より引用）

臼田：注目して欲しい点は、Pushから10分後には不正利用が開始されるというところです。

川口：早い！

 

 

臼田：本当に早いんですよね。「本当に危ないんだ」と認識して頂けるんじゃないかと思います。ですから、企業自身、開発者自身が気付く前に、攻撃が始まる状態になってしまうわけです。

攻撃が始まった瞬間に何が起きていたか。漏洩したのはPowerUserAccessのポリシーの付与されたIAMユーザーのアクセスキーでしたので、これよりさらに上の権限、アドミニストレーター権限の確認と、権限昇格の試行が最初に行われています。このお客様の場合は、それらが失敗に終わっています。もし昇格されてしまうと、ここに乗っかっているもの全てに影響が出ることもありますし、ルートユーザーすら取られてしまって、アカウントの管理権限がなくなってしまい、全てを破棄しなければならなくなるという状態になってしまう場合もありますから、本当に危険です。

権限昇格の試行の後は、EC2インスタンスが全てのリージョンで立てられるだけ全て立てられて、そこでコインマイニングが行われ始めています。ここまでが、だいたい、2、3分の間に行われます。

川口：早い！！

臼田：やりたいことが、完全にスクリプト化されているのが分かりますよね。数分のうちに、これらのことが全て実行されてしまうわけです。

漏洩から30分位経つと、AWS側から「アクセスキー漏洩していますよ」「不正に使われていますよ」と連絡が来ています。AWSさんの対応もめちゃくちゃ早いですよね。ただ、30分後には“時既に遅し”というわけで、影響範囲を確認しつつ被害を止めるために、EC2の削除や使われたIAMの削除をしていくことになります。

川口：普段使っているリージョンではなく、色々なリージョンでまとめて起きるというのもすごいですね。

臼田：この攻撃者の目的はコインマイニングなんですが、これって、1分でも、1秒でも、動いた分だけ攻撃者の利益になるんですよね。だから結構大胆に、リージョン全部にEC2をバンバン立てていく。それでバレても別に構わない、というスタンスなんです。

攻撃に気付かれにくくする方法のひとつとして、既存のリージョンを避けてマイニングを実行する攻撃者は多いようです。リージョンというのは20個位ありますが、多くの場合は1つか2つしか使わないですよね。普段使っていないリージョン監視を怠っていると、1ヶ月後位に利用料金明細を見てようやく気付く、という事態になるわけです。攻撃者は気付かれて落とされるまで稼げればいいので、何のデメリットも無いんです。

 

 

川口：普段使わないリージョンを扱えないように制限する、というアプローチはアリですか？　日本とかアメリカのリージョンしか使わない場合、他の国はオフにするか制限をかけておく。

臼田：はい、手法としてはアリです。最近新しく追加されたリージョンは、デフォルトでは無効化されていて「使いたい場合には有効にしてください」ということになっています。また、権限があれば有効と無効の切り替えもできます。ただ、実は、元々存在している十数個のリージョンはそういった設定ができないようになっていて、かつ、途中で無効化する、ということができないんです。

AWSのマルチアカウントを管理するAWS Organizationsというサービスを利用することでリージョンの制限も対応できるのですが、元々は我々のようなクラウドベンダーが使っていたシステムで、一般の利用者さんは使えない時代もありました。今では色々な仕組みが用意されて、 AWSと直接契約せずクラウドベンダーを経由して契約していても、ベンダーによっては一部の機能が提供されたりもします。ただそれでも、AWS Organizationsの管理そのものはベンダーがしている為、利用に縛りがあったりするので、なかなか使いづらいというところがあるかもしれません。

川口：AWS Organizationsは、強力な権限があるが故に、もし乗っ取れたら攻撃者としては最高ですよね。

臼田：そうなんです。そこはしっかりと管理する必要があります。ユーザーとしては基本的に、色々な仕組みを組み合わせて、こういった攻撃や脅威からAWS環境を守っていく必要があります。

導入必須！ “水際で防ぐ”ツールと請求金額アラート

臼田：これらの対策として、まず1点目としては先程話題に出た「git-secrets」を入れて頂くことをお勧めしています。gitに対して重要なクレデンシャルをプッシュしようとした時にエラーになります。“うっかり”を防ぐ為の仕組みとして、開発者さんの各端末に入れて頂ければと思います。

先ほどのインシデントの例では「Power User」という権限が漏洩していますが、そもそもそういったものをアプリケーションのコードに当てることは、本来在るべきことではありません。権限を適切に絞ることは、被害を防いだり被害の影響を小さくする上で重要なことなので、絶対にやって頂きたいですね。

2つ目の対策として、こういった漏洩や攻撃が起きたことを検知するためのサービス“Amazon GuardDuty”を紹介します。「コインマイニングしています」や「EC2がマルウェアに感染してしまってC＆Cサーバーに通信をしています」等はもちろん、「ブルートフォース攻撃を受けています」や「ブルートフォース攻撃の踏み台になってます」というところまで様々な脅威検知をしてくれます。本当に良く出来ていますので、導入必須のサービスだと思います。

あとお勧めしているのは、料金のアラートを入れることです。例えば“AWS Budgets”というサービスを利用すると、月額の予算をある程度決めておいて、20％、50％、70％に達した時点で通知を出す、というような細かな設定が可能です。予定通りにデータベースの利用料金が発生している定期的な確認にもなりますし、予想より膨れ上がっている場合は何か問題が起きていると分かります。原因はセキュリティインシデントである場合もありますし、本番環境の設定が誤っていて、想定外の料金が発生している場合の検知としても利用できます。

川口：確かに、プログラムで無限ループとか作っていたりすると、とんでもない料金になっていたりしますよね（笑）。

臼田：はい。サーバー1台の中で無限ループしているウチはいいんですけれど、AWSの仕組みを使っていると、従量課金なので大変なコトになります。実は、私もこれで、100ドルくらいを1日で持って行かれた事があります（笑）。

“AWS Lambda”という関数を実行するサービスで「ある特定の問題を検知したら自動修復する」という仕組みを組んだんです。ところがこのロジックが甘かったようで、自動修復を試みるが上手くいかずに失敗する、失敗したものをまた自動修復しようとして失敗する……という無限ループが発生していました。

翌日に料金アラートが来て、驚きました（笑）。そういった時にも、“AWS Budgets”を使っていれば、1日程度で失敗に気付くことが出来るわけです。これが1ヶ月後だったら、本当に危ないところでした。そういった意味でも、料金アラートは絶対に導入をしておいたほうがいい対策になります。

 

（後編に続く）