クラウドネイティブな環境でも「やることは変わらない」――GMOペパボにおけるインフラセキュリティ管理、7つの取り組み：1000VM規模のOpenStackとAWS、GCPの環境をどう守る

レンタルサーバやホスティング、EC支援など幅広く事業を展開するGMOペパボ。OpenStack、ベアメタル環境、クラウドとITインフラの変遷を反映したような同社のインフラ構成において、セキュリティ対策にどう取り組んでいるのか。＠ITが2022年9月に開催した「Cloud Native Week 2022秋」でGMOペパボの山下和彦氏が紹介した。

» 2022年10月31日 05時00分公開

[高橋睦美，＠IT]

この記事は会員限定です。会員登録（無料）すると全てご覧いただけます。

　GMOペパボはレンタルサーバやホスティングに始まり、EC支援事業など幅広く事業を展開してきた。それに伴い拡大してきた同社のインフラもまた、幅広い種類で構成されている。

　オンプレミスのデータセンター（DC）に構築したOpenStackや、ベアメタル環境に加え、Amazon Web Services（AWS）、Google Cloud Platform（GCP）といったクラウドサービスと、大きく分けて4種類の基盤で構成されている。AWSならば「Amazon EKS」「Amazon RDS」「Amazon ElastiCache」といったマネージドサービスを中心に利用し、GCPならば「GKE（Google Kubernetes Engine）」「Google BigQuery」などデータ分析用途で活用するとともに、DCに障害があったときの退避先としている。一方、DCのOpenStack上では複数の仮想マシン（VM）やKubernetesクラスタを動かしている。

OpenStackは1000VM程度の規模になるという

　このように、ITインフラの変遷を反映したような構成の中で、どのようにセキュリティを確保しているのだろうか。同社の山下和彦氏（技術部技術基盤チームシニア・プリンシパルエンジニア）は、2022年9月に＠ITが主催した「Cloud Native Week 2022秋」で自社内、特にクラウドネイティブな環境で、セキュリティ向上にどう取り組んでいるかを紹介した。

クラウドネイティブであろうとやるべきことは変わらない

GMOペパボ技術部技術基盤チームシニア・プリンシパルエンジニア山下和彦氏

　クラウドネイティブのような新しい環境には新しいセキュリティが必要だ――と思ってしまいそうだが、山下氏の意見は異なり、「あまりこれまでと変化はない」という。

　「『機密性』『完全性』『可用性』というセキュリティの三要素は変わらず普遍的なものとしてあり、クラウドネイティブ技術であろうと、それに基づいた対応をする必要があると考えています」（山下氏）

　コンテナであれば、利用するパッケージや特権管理において脆弱（ぜいじゃく）性を含まない状態にし、サービスメッシュ間の通信ならば認証、認可を経た上で暗号化する……といった具合だ。オンプレミス環境に構築したサーバで、最小権限の原則に基づいてアカウントを管理し、パッチを適用して最新の状況を保つのと何ら変わらない。

　とはいえ、クラウドネイティブな環境で使われる宣言的APIには、宣言的であるが故にCI（継続的インテグレーション）サイクルの中でテストや監査がしやすいといったメリットがある。そのため、開発の前工程で脆弱性を発見し、影響が小さいうちに修正させていく「シフトレフト」との親和性は高い。

　GMOペパボではこうした特質も踏まえつつ「クラウドネイティブだからといって、これまでと異なる対応はしない」という原則に基づいてセキュリティ対策を実施してきた。

　ただ、「コンテナやKubernetesは比較的新しく、かつ低レイヤーの技術も使われている難しい技術領域です。マネージドサービスで運用するといっても、要素技術やプラットフォームに対する知識がないと、安全に運用するのは難しい印象です」と山下氏は言う。そこでGMOペパボでは、Kubernetesクラスタの構成管理を担うエンジンを自社開発するなど、組織横断的な形で技術にキャッチアップし、内部で技術を積み上げながら安全に運用できる状態を作り出してきた。

アプリケーションからコンテナ、ライブラリ、組織に至るまでの7つのポイント

　山下氏によると、GMOペパボは7つの側面からセキュリティの取り組みを進めてきた。

外部からの脅威

　1つ目は「外部からの脅威」という観点だ。Webサービスの脆弱性を突こうとする攻撃を検知、ブロックする「Webアプリケーションファイアウォール」（WAF）で保護している。もしWebアプリケーションに脆弱性があってもある程度は防御できる上に、既存のアプリケーションに手を入れることなく柔軟に導入できることが利点だという。

　一方で、正常なアクセスを攻撃として検知してしまう「偽陽性」（フォルスポジティブ）との戦いに始まり、性能劣化やシグネチャ更新、管理の工数など、まだ工夫を凝らす余地もあるという。

　外部からの脅威に備えてもう一つ実施しているのが、ポートやコンテンツのスキャンだ。意図せずリソースを公開する事態が起きないよう、「ECS Fargate」から自社DCに対してポートスキャンをかけ、「意図しないポートを公開していないか」を継続的に検査している。

ポートやコンテンツをスキャンして検査

　同様にOpenStackやAWS上のサービスは、AWSのSecurity GroupとGMOペパボの社員（当時）が作成した「sg_inspector」を組み合わせ、意図しないポート開放などを検知するとSlackなどに通知する仕組みを作り上げた。コンテンツも「password.php」といったファイルが意図せず公開されていないかを確認する「Pmrコマンド」を開発し、運用している。

異常検知

　2つ目の観点は「異常検知」だ。「もし防御が破られ、何かしらの問題が起きたとき、それを検知できないとずっと攻撃され続けてしまう」（山下氏）。そこで、異常を速やかに検知する仕組みも複数用意している。

　まずサーバの異常検知において大きな役割を果たしているのが、クライアント／サーバ型の監視システム「Wazuh」と「Falco」だ。

　Wazuhは4つの観点で活用している。1つは、サーバ内のファイルに変更が加えられたり、コマンドが実行されたりしたことを通知する「改ざん検知」だ。いつ、どのユーザーがどのバイナリファイルを実行したかを事細かく通知できる。「ただ、大量に通知が送られてくると見落としのリスクがあるため、自社で『Wazuh Notifer』というプロダクトを作り、通知を最適化しています」（山下氏）。他にも、OSやパッケージのバージョン管理と脆弱性管理や設定ファイルの監査にも活用し、サポート期限の切れたOSが動作し続けていたり、クリティカルな脆弱性が放置され続けたりしていないか監視するため活用している。

　FalcoはKubernetesで利用可能な脅威検知エンジンだ。意図しないSecretへのアクセスや外部通信の発生、コンテナの実行を検知し、ダッシュボードで把握したり、Slackに通知したりできる。

　「FalcoはKubernetesに特化したツールですが、ホスト側の情報も取得できるため、Falcoだけで脅威検知および管理も可能です。しかし、われわれの環境にはKubernetesだけでなく、VM上で動作しているアプリケーションもあります。統合的に管理するため、Wazuhはホスト全体の管理に、FalcoはKubernetesよりも上の部分の管理にという形で活用しています」（山下氏）

WazuhとFalcoの使い分け

　サーバだけでなく、アプリケーションの異常検知にも取り組んでいる。アプリケーションの例外を管理できるSaaS「Sentry」と、アプリケーションパフォーマンス管理（APM）を実現する「Datadog/ElasticAPM」を、サービスの可用性に合わせて組み合わせ、パフォーマンスが極端に低下したときなどにアラートを飛ばす形だ。

　さらに、通信経路の暗号化に加え、「Fluentd」と「Apache Kafka」「Amazon S3」によるパイプラインを構築してログ管理も実施している。「ログは基準に応じてクラウドにアップロードして長期保存しています」（山下氏）。OSやAPIの監査ログはもちろんだが、もし攻撃を受けて情報を盗み取られてしまった場合に「どのような情報が抜かれたか」を特定する目的で、データベースに発行されたクエリのログも全て保存している。さらに、異常な挙動が発生した際の調査のため、アプリケーションのログも保存対象としているという。

パイプラインの一例

コンテナセキュリティ

　3つ目の取り組みは、コンテナセキュリティだ。ここではオープンソースソフトウェア（OSS）の「Trivy」と「Trivy-operator」を用いて、GitHub Enterpriseのコンテナイメージレジストリに登録されているイメージと、Kubernetesで実行されているコンテナイメージ、両方で脆弱性の有無をチェックしている。もし脆弱性が見つかれば、自動的にGitHubのIssuesに登録する仕組みだ。自動的にアップグレード、更新をかけて脆弱性を解消する仕組みを「Pinject」で実装し、検知後の自動収束まで実現している。

　コンテナセキュリティに関して山下氏は「1つ大切な考え方があります。イメージスキャンを漏れなく実施することです。『テストでしか利用しないイメージだからスキャンする必要はない』と意思決定してしまいがちですが、昨今ではサプライチェーン攻撃のリスクもあります。何かのはずみに脆弱性が顕在化してしまうことも起こり得ます。外部に公開しないコンテナイメージでも、脆弱性がない状態であることを確認して使うのがベターだと考えています」とコメントしている。

アプリケーション、ライブラリ

　4つ目はアプリケーションやライブラリの対策だ。「Dependabot」と「Renovate」を利用し、自動的にパッケージやライブラリを更新していく体制を整えている。これら2つのツールでは、パッケージ管理ツールの構成ファイルを確認し、新しいパッケージがリリースされたり、脆弱性が判明したりすれば自動的に更新してプルリクエストを発行する。

　さらに、利用しているイメージに更新やリリースがあった場合に自動的に書き換える「Dockerfile」「development.vml」も併用している。サーバサイドのミドルウェアも、unattended-upgradeやyum-cronを用いて、セキュリティリリースのみを自動更新する形だ。

　こうした仕組みによって、常に脆弱性が修正された最新のパッケージやライブラリに更新される仕組みを整えているが、一方で更新により、アプリケーションが正常に動かなくなるリスクもある。そこで「ホストネームの末尾が偶数のものは水曜日に、奇数のものは金曜日にといった具合に更新のタイミングをばらすことで、自動更新によって全てのサービスがダウンしないようリスクを分散しています」（山下氏）

Kubernetesセキュリティ

　Kubernetesに関してもさまざまな対策を実施している。その1つが「Gatekeeper」を利用したマニフェスト監査だ。GMOペパボでは、Kubernetes利用に関するドキュメント「Podセキュリティの標準」に準ずる形で、Regoという言語を用いてルールを定義している。そして「不要な特権を持たせたマニフェストはアプライさせない」といった具合に、ポリシーに反するマニフェストの適用を禁止することで、デフォルト状態でセキュリティを確保する形だ。

　「コンテナは、仮にセキュリティ的に陥落するようなことがあってもホストOSに影響を与えないようにする技術ですから、特権を与えないことが非常に大切です。何かあったとしても影響を最小限にとどめるためホストネットワークと分離して運用したり、可能であればRead Onlyのコンテナとして運用したりするのが望ましいと考えています」（山下氏）

マネージドサービスの管理

　マネージドサービスの管理にも留意している。Amazon S3のバケットを第三者に公開する状態で設定してしまうといったケースが典型例だ。

　「マネージドサービスは非常に便利ですが、仕様を知らずに設定ミスをしてしまうことがあります。とても初歩的なミスであっても、往々にしてそれがセキュリティホールになってしまいます」（山下氏）

　こうした事態を防ぐため、「Terraformなどを利用してコードで構成を管理する」「AWS Security Hubをはじめとする、クラウドサービスが提供する、サービスを安全に活用するための仕組みを利用する」という2つの観点で対策を実施している。

　Terraformを用いたコードによる構成管理はさまざまな企業で採用されており、GMOペパボもその一社だ。「レビュープロセスで意図しない設定の混入を防ぎ、かつ、これまで人手で実施していた作業をコード化することで、確認行為を資産化できます。さらに自動デプロイによって、違う環境にデプロイしてしまうといったデプロイ時のヒューマンエラーを避けることもできます」（山下氏）

　AWS Security Hubは、AWSのベストプラクティスに基づき、セキュリティ上望ましくない設定があれば「ここに問題があります」と深刻度などとともに通知してくれるサービスだ。非常に便利だが、GMOペパボの場合、複数のサービスを展開し、それぞれにアカウントが分かれ、中にはマルチリージョンで運用しているサービスもあるという特殊な事情がある。

　「管理すべき対象が掛け算で増えていくため、非常に運用が煩雑になるという課題がありました。そこでAWS Security Hubの定義をYAMLで記述できる『Control of Controls』というソフトウェアを社員が開発しました。YAMLを用いることで、ベースラインを共通項目として定義したり、リージョンごとの定義を集約したりできます」（山下氏）。AWS Security HubとControl of Controlsによって、コードによる構成管理を徹底し、安全に管理できているとした。

組織的な取り組み

　最後は組織的な取り組みだ。GMOペパボでは「セキュリティキープ」「定期的な監査」「インシデント管理の自動化、平準化」という3つの取り組みを継続している。

　セキュリティキープはあまり聞き慣れない言葉だが、セキュリティ上の課題を解決するために同社が定期的に開催しているミーティングのことだ。「各サービスで利用しているプログラミング言語やOSが古くなっていれば、いつまでにバージョンアップすべきか、そのためにどんな支援が必要かといった情報を整理、検討しています」（山下氏）。会社として導入を義務付けているソフトウェアがきちんとインストールされているかどうかの確認や、外部監査の指摘事項の共有、対応状況の確認など、さまざまな情報を「キープ」しているという。

　また、外部監査や内部の監査チームによる定期的な監査（脆弱性診断）ももちろん実施している。脆弱性の有無に加え、各種ミドルウェアの設定やログ保全の設定など、細かなところまで確認している。それも、一度検査を受けて終わりではない。監査結果をセキュリティキープを通して共有し、収束させていく取り組みを継続している。

　ただ、これだけさまざまな対応を進めていてもなお、インシデントは発生してしまうものだ。「ひとたびインシデントが発生すると、さまざまな話がトッププライオリティで降ってきてしまうため、冷静に対応するのは困難だと考えています。そこで、誰でもマニュアルに沿って対応できるよう『sssbot』を開発しました」（山下氏）。Slackでsssbotに話し掛けると、専用チャンネルの作成や担当の割り振り、参照すべきマニュアルの案内などを、インシデント対応のワークフローに沿って進めていくことができる。さらに、Slackのピン機能を生かし、その経験を全社で共有して生かせるよう、ポストモーテムの作成までできる形だ。