AWSの「AWS Lambda」のサーバレスプラットフォームを使用して、Node.jsアプリケーションを起動したとしよう。アプリケーションに含まれる依存関係は全て侵害を受ける可能性があり、組織のサイトに悪意のあるコードがインストールされる事態を招く恐れがある。このような事象が発生すると、ユーザーのデータや知的財産が失われるかもしれない。

　継続的インテグレーション（CI）や継続的デリバリー（CD）手法向けのシステムを使うと、反復処理の速度が上がる。このようなシステムは、小さな単位で導入でき、大抵はバグの数が少なくなるため、おおむね好ましい。だが、CI／CDツールはパッケージや要件の収集にサードパーティー製のシステムを使用する傾向があり、そのようなリポジトリは攻撃を受ける恐れがあるのが欠点だ。

　例えば最近発生した機能停止によって、Node.js開発者向けパッケージ管理ツール「npm」のコードリポジトリに深刻な脆弱性があることが判明した。安全だと考えられていたパッケージが、ほとんど同じ内容だが攻撃コードを含むものに置き換えられていた。npmパッケージにはビルドと導入のフックを含めることができるため、アプリケーションの導入に使用するAWS資格情報の盗難から、クレジットカード番号やパスワードの収集まで、あらゆることが可能になる。安全を確認して長年使っているパッケージでさえ、新しい導入の際に攻撃を受ける恐れがある。

　これまでは、IT運用チームがハードウェアを制御することでこのようなリスクをある程度緩和してきた。既知の悪質なIPアドレスにクレジットカード番号のアップロードを試みるなど、問題を発生させる怪しいネットワークトラフィックは、専用のファイアウォールを導入してアクセスを禁止することもできた。これからもIT運用チームがITセキュリティの役割を担うことに変わりはないが、クラウドやサーバレステクノロジー採用の動きと共に、このような制御の多くは運用チームの手を離れることになる。

CI／CDプロセスに検出を追加する

　明確に定義されたCI／CD手法のあるチームでは、既にビルドプロセスに自動単体テストを組み込んでバグを検出しているはずだ。自然な流れとして、ビルド段階でセキュリティ脆弱性のテストも必ずしているだろう。バグや脆弱性の検出には、SnykやOpen Web Application Security Project（OWASP）をはじめとするさまざまなツールや組織が役立つ。IT運用チームは通常、このようなツールのセットアップに責任を持つ。ツールの多くは、ビルドの前に1回スキャンを実行し、運用環境のシステムで継続的にチェックを実行するように設定できる。

　ITセキュリティの役割を担っているか、ITセキュリティに関心の高い運用チームは、カスタム社内リポジトリを作成するのもよい。例えば、「npm Enterprise」を使用すると、機能互換性のあるバージョンのnpmを含めることができる。このツールは事前承認されていないサードパーティー製プラグインのインストールを防止する。ファイアウォールの内部に導入することで社内チームが保守でき、迅速で、安全性と信頼性の高いプラグインの導入が可能になる。

　システムを運用環境に移さなければ、発生原因を特定できない攻撃もある。例えば、ユーザーのアカウントが漏えいする恐れがあり、場合によっては、開発者のアカウントが攻撃を受ける可能性もある。

　AWSを使用する場合、各サービスに厳格なIDアクセス許可があることが非常に重要だ。例えば、ユーザーのAPIでは恐らく、新しいEC2インスタンスを作成したり、ユーザーを削除したりできないようになっている。データベース全体を誤って削除することがないとはっきりするまでは、開発者アクセス許可は徐々に与えるべきであり、書き込みアクセス許可は与えてはならない。ルートAWS資格情報は、最高技術責任者（CTO）以外が持つべきではない。

　もう1つ重要なのは、IDとアクセス管理（IAM）ユーザー全員に対して多要素認証（MFA）トークンの設定を求めることだ。このようにすると、AWSの「Amazon S3」のバージョン管理を有効にしたり、S3オブジェクトの削除にMFAトークンを要求したりするのに役立つだろう。

　重要なデータは必ず別の場所にバックアップする。機密データの場合は、暗号化する必要もある。しかしバックアップを別の場所に保存するのは、そのデータが攻撃にさらされる恐れを増やすことにもなる点も留意したい。バックアップを増やすことは必ずしもメリットばかりではない。

　ほとんどのクラウドプロバイダーが、マネージバックアップオプションを用意している。そのようなオプションを必ず最初に検討する。

異常な活動の監視

　厳格なポリシーを設定し、ITセキュリティの役割専門の担当者を配置しても、何らかの問題が発生することは避けられない。誤って資格情報が漏えいすることもあれば、誰かのPCにインストールされた悪意のあるコードによって資格情報が公開されることもある。

　クラウド環境での活動を監視することも重要だ。AWSユーザーの場合、通常は同社の「Amazon CloudWatch」を通じて監視する。「Microsoft Azure」の場合は、同社の「Azure Operational Insights」「Azure Application Insights」などの監視ツールの利用を検討する。

　カスタムアラームを設定することも役立つ。IAMアカウントが普通のパターンとは異なる操作を実行しているといった、異常な動きを発見するのに有効だ。通常とは異なる動作はシステムへの不正アクセスを示す場合がある。

　エンドユーザーの問題を特定するには、複雑な手法が必要になることもある。中国からアカウントへのログインを試みたユーザーがその1時間後には米国のカリフォルニアからログインしている、というように明白に分かる問題がある一方、なかなか問題が分からない場合もある。異常検出を導入したり、疑わしい要求については手動で承認したりするようにしておくと、好ましくない活動の防止に役立つ。このような規則の管理に役立つサービスが幾つか存在する。また、Auth0が提供する「Auth0」のような認証サービスには、既に異常検出が組み込まれている。

　Webアプリケーションファイアウォールを導入すると、コミュニティーで事前定義された規則や、IT運用チームが特定したパターンに基づくカスタムロジックを使用してトラフィックをブロックし、Webベースアクセスポイントの保護を強化できる。

　例えばWordPressで作成したカスタム社内アプリケーションのwp-admin URLに誰かがアクセスを試みている場合、何かをハッキングしようとしている可能性がある。標的となる脆弱性の多くは、WordPressやPHPスクリプト言語で記述されたアプリケーションだ。そのため運用チームは疑わしいURLに対する要求に目を光らせ、問題を引き起こすIPアドレスからのトラフィックを全てブロックできる手だてを整えておく必要がある。