NRIのクラウドガイドライン策定者に聞く、網羅的で統一されたセキュリティを実現する方法
これからの開発者に意識してほしい、マルチクラウドセキュリティの要点
2021年05月14日 08時00分更新
アプリケーション開発者自身でも手軽にIT環境を構築し、利用できるパブリッククラウド。しかし、手軽であるがゆえに、設計ミスや設定漏れなどに起因するセキュリティインシデントも起こりやすい。サービス間で機能や設定項目が異なるマルチクラウド環境になれば、この問題はますます複雑化するだろう。
これまであまりセキュリティを意識してこなかった開発者やエンジニアも、これからはセキュリティ意識を高め、対策の一翼を担う必要に迫られている。だが、マルチクラウド環境において網羅性のあるセキュリティ対策を実行するにはどうすればよいか、開発者の立場で特に注意すべき点とは何か、手がかりなしで考えることは難しい。
今回は、OCIを始めとするマルチクラウドを活用している野村総合研究所（NRI）において、クラウド利用時のセキュリティガイドライン策定を担当する佐古伸晃氏に、これからの開発者がセキュリティ対策において担う役割や、網羅的なセキュリティの考え方と実践のポイントについてうかがった。
野村総合研究所（NRI）品質監理本部 情報セキュリティ部の佐古伸晃氏。佐古氏はOCIユーザーグループのOCIjpが3月に開催した「OCIjp #16 今さら聞けない!? セキュリティのイロハ」でも登壇、講演した
セキュリティ対策における開発者の「役割変化」
佐古氏が策定に携わるセキュリティガイドラインは、NRIの社内エンジニアが安全にクラウドサービスを使うために考えるべきこと、遵守すべきことを具体的項目にまとめたものだ。現在のところ、OCIのほかAmazon Web Services（AWS）、Microsoft Azure、Google CloudといったIaaS、GitHubなどの分散バージョン管理システム、Docker／Kubernetesといったコンテナ基盤についてのガイドラインを提供している。
こうしたガイドラインを社内に提供する背景には、セキュリティ対策における役割分担の変化がある。前述したとおり、これまでのセキュリティ専任担当者やインフラ担当者だけでなく、開発者もセキュリティ対策に“参加”しなければならないからだ。佐古氏は、そうした変化の理由をいくつか挙げた。
まずは、アプリケーションがオンプレミス環境からクラウド環境に移行していることだ。クラウド環境は、物理的、ネットワーク的に外部と隔離されている自社データセンターのオンプレミス環境とは大きく異なる。
「オンプレミス環境でもクラウド環境でも、守るべき情報資産は同じです。ただし、クラウドは『インターネット越しで使う』前提があり、世界中のどこからでもアクセスできます。インターネットは常に攻撃にさらされており、さらに、権限設定しだいでその環境はフルオープンにもできてしまいます。そのため、オンプレミスで中心的だったネットワークベースの防御から、認証・認可や暗号化といったデータ保護なども含めた多層的な対策へと、セキュリティ対策の重心が移ってきていると言えます」
また、クラウドネイティブな開発スタイルもセキュリティの考え方に影響を与えているという。旧来のウォーターフォール型開発では、長い開発期間を経て、リリース前（インターネット公開前）の最終段階でセキュリティチェックを行うケースが多かった。しかし現在では、ビジネスの変化に即応するため、短期間で開発とリリースを繰り返すアジャイル開発が求められるようになっている。
「開発者自身が、設計や環境設定といった最初の段階からセキュリティを意識した作りにしておかないと、最終段階になってセキュリティの問題が見つかり、リリースが遅れるような影響も出かねません。さらに、短い開発サイクルの中で常にセキュリティチェックを繰り返していくためには、そうした作業の自動化や省力化といったことも考えなければならないでしょう」
加えて、クラウドにおいては、本番環境よりも開発環境やサンドボックス環境のほうがセキュリティの不備が生じやすいという。「本番データを扱っていないから」と軽い気持ちで開発環境のセキュリティ設定を甘くしたり、試用のために立ち上げたサンドボックス環境をそのまま放置したりすることで、セキュリティの“穴”を生んでしまうケースだ。これもまた、開発者自身がセキュリティを意識し、対策を取らなければならない理由のひとつと言える。
開発者が参照すべきセキュリティフレームワークはどれか
対策漏れのない、網羅性のあるセキュリティ対策を行うためには、包括的なフレームワークやガイドラインが必要となる。
NRIのクラウドセキュリティガイドラインは、「基本ガイドライン」と「個別ガイドライン」の2種類で構成されている。基本ガイドラインは「ネットワークによるアクセス制御」「IDによる認証・認可」など7項目の「考え方」を、一方で個別ガイドラインはOCIやAWSなどの各クラウドにおける「具体的な対策手順」を示すものとなっている。
NRIの基本ガイドラインでは、クラウドセキュリティで考えるべき事項を7種類に分類している
佐古氏は、このガイドラインを策定するにあたって「CISコントロール」と「CISベンチマーク」というフレームワーク／ドキュメントをベースにしたと語る。CIS（Center for Internet Security）は、米国の政府機関や企業、学術機関などが協力して、インターネットセキュリティの標準化に取り組む団体であり、CISコントロールとCISベンチマークは、クラウドセキュリティにおけるデファクトスタンダードの1つとなっている。
著名なセキュリティフレームワークとしては、ほかにも「NISTサイバーセキュリティフレームワーク」「PCI DSS」などが存在するが、佐古氏は「CISは具体的な技術対策を取り扱っており、開発者が参照するのに適している」と評価する。
主要クラウドセキュリティフレームワークの特徴。CISコントロールは、サイバー攻撃への具体的な技術対策を強みとしている（出典：NRIセキュア ブログより引用、一部改変）
NRIの基本ガイドライン／個別ガイドラインと同じように、CISコントロールはセキュリティの「考え方」、CISベンチマークはクラウドごとの「具体的な対策手順」をまとめている。
「簡単な例を挙げれば、CISコントロールでは『すべてのアカウントに有効期限があることを確認する』と定めており、CISベンチマークではその具体的な対策として『認証トークンを90日以内にローテーションする』という設定手順をクラウドベンダーごとに紹介しています。CISコントロールを“横軸”、CISベンチマークを“縦軸”としてクロスで見ていくことで、網羅性があり、なおかつマルチクラウド間でもレベルが平準化されたセキュリティ対策ができるわけです」
このように整理されているため、たとえば開発者が「AWSではこういうセキュリティ設定だったが、OCIではどうすればよいか」と悩んだときにもすぐに手順を参照できる。また、CISベンチマークで行う個々の対策がどのような考え方に基づくものなのかを、CISコントロールにさかのぼって知ることもできる。
「現場では『システムの都合上、どうしてもルールどおりには設定できない』ということも起こります。しかし、そのルールの基になった考え方に沿っていれば、代替コントロールでの対策も実施できます」
CISコントロールが取り上げているセキュリティ領域一覧（出典：NRIセキュア ブログ）
CISベンチマークが記載しているセキュリティ推奨事項の例。主要クラウドベンダーのそれぞれに対応するドキュメントが提供されている（出典：Center for Internet Security）
ちなみにCISベンチマークでは、Webコンソール（GUI）操作と合わせてコマンドライン（CLI）操作による設定手順が紹介されている。CLI操作はシェルスクリプトなどを用いた自動化への転用がやさしい。また、CLI操作の自動化ツールやサービスもすでに提供されていると佐古氏は説明する。
自社個別要件も取り込んだ「3段階のルール構成」、社内浸透に向けた取り組み
業界標準のセキュリティフレームワークとは別に、クラウドベンダー各社も自社サービスのベストプラクティスをドキュメントとして提供している。佐古氏は、これらも組み合わせて「3段階の構成」で考えることで、より網羅性が高いルールができると推奨する。
具体的には、まず共通対策としてCISベンチマークの共通的な対策方針を基盤とし、そこにクラウドベンダー各社のベストプラクティスを組み合わせ、最後に自社の個別要件を独自ルールとして追加するという考え方だ。実際にNRIでも、この3段構成の考え方でガイドラインを定めているという。
CISベンチマーク＋クラウド各社のベストプラクティス＋自社独自ルールという「3段階の構成」により、網羅性の高いルールができる
もうひとつ、セキュリティ対策はルール策定だけでは終わらない点も強調した。策定したルールが適用されているかを申請時に審査するとともに、継続的に監視してルール違反を検知する作業、利用者（開発者）側で継続的に設定を更新する作業、そして全社的なセキュリティレベルの統一や継続性、網羅性を担保する教育・啓蒙の活動も必要だという。
「こうした取り組みは、一度やれば終わりではありません。クラウドでは新たなサービスが次々に登場しますから、それに合わせてルールも設定も継続的にアップデートしなければなりません。また教育・啓蒙の面でも、最新のセキュリティインシデント、サイバー攻撃事例を題材に学ぶことが大切です。4つの取り組みを継続的に回していける体制づくりが必要でしょう」
ルール策定だけでなく、そのルールの適用と監視、継続的な更新、教育・啓蒙も同時に取り組む必要があると説明した
セキュリティ視点から見たOCIの特徴、優位点は？
冒頭でも触れたとおり、NRIではマルチクラウド活用にも積極的に取り組んでいる。セキュリティの視点から複数ベンダーのIaaSを見比べたとき、OCIの特徴や優位性はどこにあるのだろうか。佐古氏は次のように語る。
「OCIは比較的後発のクラウドということもあり、先行するベンダーがとっているセキュリティ対策をきっちりと踏襲し、課題も解消してからサービスを出してきているイメージがあります」
より細かな設定ができるとなお良いと感じることもあるが、全般には「先行ベンダーとの差がそれほどあるとは考えていない」という。
OCIで良い点としてはまず、データの暗号化をオプション扱いとせず必ず実施し、ユーザーが解除できない点を挙げた。OCIでは「エンドトゥエンドのデータ暗号化」という基本ポリシーを持っており、ストレージやデータベースに格納するデータ、グローバルなバックボーンネットワークを通るデータはすべて、強制的に暗号化される。
「セキュリティにおいて、データの暗号化は“最後の砦（とりで）”と言えます。それに対して、オラクルは『どんなデータでも必ず暗号化して守る』という明確なメッセージを持っています。データベースの会社ということもあって、データの取り扱いについては強く意識していると感じます」
データの暗号化にかぎらず、OCIのセキュリティは全般に“安全寄り”のデフォルト設定となっており、リスクのある変更ができない設定項目も多いという。佐古氏は、CISベンチマークで取り上げられている設定推奨項目数が他社よりも大幅に少ないことを指摘し、OCIは「デフォルトでセキュリティ対策がなされているので、ユーザーにとってはシンプルで悩むポイントが少ないのでは」と述べた。
リスクのある設定やアクティビティを自動検知・是正するサービスである「Oracle Cloud Guard」を、OCIユーザーに無償で提供している点も優れていると評価する。Oracle Cloud Guardは、各サービスの設定やアクティビティを継続監視して、OCI環境全体のセキュリティ状況を可視化するツールだ。たとえば、OCIを利用するユーザーに多要素認証（MFA）の設定が行われていない場合も検知することができる。同様のセキュリティツールは他のベンダーでも提供されているが、OCIは追加コストなしで利用できる点が大きな違いだと佐古氏は語る。
「開発環境など小さな環境では、クラウド利用料がそれほどでもないのに、セキュリティにまでコストをかけるのは……という心理的障壁が生まれがちです。Oracle Cloud Guardのように無償ならば、そうした環境でも導入しやすいですし、可視化すればセキュリティ課題が見え、対策をしなければならないという意識付けにつながるでしょう」
「Oracle Cloud Guard」は、OCIのグローバル全体のさまざまなサービス設定やアクティビティを一元的に監視し、通知・是正することで安全なクラウド利用をサポートする
＊ ＊ ＊
佐古氏は、これからは開発者とセキュリティ担当者が歩み寄って“分断”をなくし、セキュリティ意識の改革を進めていく必要があるとまとめた。佐古氏自身も、社内のクラウド勉強会などに参加し、積極的にセキュリティの話題を話すようにしているという。
「開発の後工程になるほど、セキュリティ上の問題を修正する対策コストは大きくなります。セキュリティのシフトレフトに向けた意識改革を図り、そのためにどうすればよいのかを開発者から気軽に相談してもらえるような関係づくりを進めています」
日本オラクルでは、毎週オンライン開催しているコミュニティMeetupセミナー「Oracle Code Online」において、セキュリティをはじめとしたさまざまなテーマで開発者向けの知見をお伝えしている。開発者の皆さんはぜひともこのコミュニティにメンバー登録して、これからの幅広い学びに生かしていただきたい。
■Oracle Code Online https://oracle-code-tokyo-dev.connpass.com/
（提供：日本オラクル）
