GMOペパボの運用体制から学ぶ - クラウドセキュリティ整備の要所

GMOペパボは、プライベートクラウド、Amazon Web Services （以下：AWS）、Google Cloud Platform（以下：GCP）を活用し、レンタルサーバの「ロリポップ!」や「heteml」といったホスティング事業を提供している。

7月13日、14日に開催された「TECH+ フォーラムクラウドインフラ Days 2023 Jul. ビジネスを支えるクラウドの本質」に同社技術部技術基盤チームシニア・プリンシパルエンジニアの山下和彦氏が登壇。マルチクラウド環境において同社がどのようなセキュリティの取り組みを行っているのかを解説した。

GMOペパボが持つ4つのインフラ構成

講演冒頭で山下氏は、同社の持つ4つのインフラ構成を紹介した。まず、同社がサービス合計1000VM規模で利用しているのがOpenStackだ。OpenStackで管理するVirtual Machine（仮想マシン、以下VM）の上にKubernetesを構築し、自社開発のエンジンでデプロイしている。最近の同社は、物理サーバの上にOpenStackを構築し、OpenStackでVMを起動。その上にKubernetesを置き、そこでコンテナを動かすサーバ構成が主流になりつつあるそうだ。

GMOペパボのOpenStackの構成

この他に、ホスティングサービスや各種基盤ではBareMetalを、Amazon Elastic Kubernetes Service （以下：EKS）やAmazon Relational Database Service（以下：RDS）といったマネージドサービスではAWSを、データ基盤のサーバとしてはGCPを利用している。

「TECH+ フォーラムクラウドインフラ Days 2023 Jul. 『ビジネスを支えるクラウドの本質』」その他の講演レポートはこちら

外部からの脅威への対策と異常の検知

同社での取り組みについて山下氏は「自社で定めたセキュリティガイドラインに基づいて、粛々と実行している」と語る。では実際にどのような対策を講じているのだろうか。

まず外部からの脅威への対策としては、入口にファイアウォールを置くWeb Application Firewall（WAF）を導入している。配布したソフトウエアをAmazon Elastic Container Service （以下：ECS）のFargate上で実行してポートスキャンを行い、意図せず開かれているポートを検知する仕組みだ。他にも、山下氏が開発した「Pmr」というコマンドにより、意図しない公開ファイルがないか、コンテンツスキャンも行っている。

万が一外部からの攻撃が成立してしまった場合のサーバの異常は、オープンソースのセキュリティ監査基盤・Wazuhで検知している。さらにWazuhからの通知が正しい改ざん検知であるかどうかを判断し、本当の改ざんを検知した場合のみSlackに通知させるソフトウエアも導入しているという。

「大量の通知が来た場合でも、通知を最適化することで見落としを防ぐことができます」（山下氏）

GMOペパポでは適切な改ざん通知のみが届くようカスタマイズしている

また、Wazuhが送り出したソフトウエアの異常や改ざんの情報を、Metabaseのデータベースにインポートしている。同社に最適なUIで可視化されていると言い、OSのバージョン管理と脆弱性検知も可能だ。さらに、Sentry、Datadog、Elastic APMの3つを使い分け、顧客用、社内用のアプリケーションの異常検知を行っている。

通信の暗号化も必須だ。これには鍵を一元管理できるHashiCorp Vaultを用い、PKI基盤を利用したTLS通信を行っている。同じくHashiCorp社のConsul Templateなどのソフトウエアと連携させることで、証明書の管理も自動化できる。証明書を短命なものにしておけば、ネットワーク同士をつなぐ鍵が流出しても、影響を小さく抑えられるのだ。

コンテナイメージスキャンは「漏れなくやる」

コンテナについてはイメージのスキャンにより、ファイルシステムの脆弱性を検知している。オープンソースのソフトウエア・Trivyを使い、漏れなくスキャンをかけることで、公開鍵と秘密鍵のセットが含まれていないか、パッケージの脆弱性がないかの検知が可能だ。

同社では複数の事業を提供しているため、コンテナイメージも大量に存在する。そのため、脆弱性が検知された場合に個別に対応するのは難しい。そこで、「Pinject」と呼ばれるソフトウエアを自社開発し、OSのパッケージ更新コマンドが自動的に適用されるようにしているという。

コンテナイメージスキャンについて山下氏は、「漏れなくやることが重要」と強調した。

「CI（Continuous Integration、継続的インテグレーション）でしか使わないものでも、外部との接触があるならば、必ず検査すべきです。開発環境のように外部公開していないものでも組み合わせによってアタックサーフェスができてしまうケースも散見されています。サプライチェーンなどが影響を受ける可能性があるのであれば、全て検査すべきでしょう」（山下氏）

アプリケーション・ライブラリの更新は2種類を活用

アプリケーション・ライブラリについては、DependabotまたはRenovateで自動更新している。これもサービスが多いと更新が膨大な数になるため、同社では大きく2つの戦略を採っている。

1つ目は「オートマージ」で、パッチバージョンはCIが通ればマージすることとし、メジャーバージョンアップについては、担当者が確認したうえでマージする。

2つ目は、「プログレッシブデリバリー」の活用だ。リリース後に問題が起きた場合、メトリックスに基づいて自動的にロールバックできるので、安全性も確保できる設計だ。

サーバサイドのライブラリも自動更新だが、これも万一の際の影響を最小限にするため、全てのサーバを同時に更新せず、タイミングをずらしながら更新しているという。

Kubernetesについては、Gatekeeperを利用したマニフェスト監査を行っている。ここで重要なのは「コンテナを正しく使うこと」だと山下氏は言う。例えばコンテナに特権を与えない、ホストネットワークと共用しないなど、Podセキュリティの基準に従って運用しているそうだ。

こうした権限チェックを行えるGatekeeperのひな型は、オープンソースで提供されている。「これを適用するだけでKubernetesが提供するPodセキュリティの標準に準拠することができるので、すぐにやってほしい」と山下氏はアドバイスした。

マネージドサービスではコードによる構成管理が有効

マネージドサービスをよく分からないまま使っていると、「簡単にセキュリティホールができてしまう」と山下氏は指摘する。基本的にはTerraformなどを利用してコードによる構成管理を行うこと、そして例えばAWSならAWS Security Hubといった、マネージドサービスが提供するセキュリティ管理サービスを利用することが望ましいと提案した。

その上で、マネージドサービスが提供するコードによる構成管理では、レビュープロセスで人の目が入るため意図しない設定の混入を防げる、人が見たものをコード化するため確認行為を資産化できる、適用まで自動化することでヒューマンエラーを避けられるといったメリットがあるそうだ。