SaaS 機能としてセキュリティを組み込む方法: ガイド

この記事では、SaaS プラットフォームとの間でよりきめ細かく、より安全な接続を提供する方法を紹介します。最終的な結果は、SaaS プラットフォームの自然な拡張のように見える総合的なソリューションであり、エンタープライズ向けプランの機能として、またはすべての顧客に対する競争上の差別化要因として提供されます。デモの実行に必要な合計時間はわずか数分です。また、舞台裏で何が起こっているかを詳しく調べて、魔法がどのように機能するかを説明します。 まず、なぜこのような特別なニーズが生じたのか、背景を説明し、従来の実装の欠点を強調したいと思います。なぜなら、古いアプローチはもはや機能しないからです。 セキュリティを機能として考え始める必要があります。エンジニアリング担当副社長、製品マネージャー、製品オーナーであれば、セキュリティに時間を割き、開発者がより優れた、より安全なインフラストラクチャを構築できるようにしてください。 — Stack Overflow の創設者、 ジョエル・スポルスキー 今後 10 年間で最も成功する製品は、現状維持のアプローチではもはや十分ではないと認識している製品です。Joel の言葉を鵜呑みにする必要はありません。Apple が最近発表した の詳細を読んでみてください。過去 20 年間で最も成功した企業の 1 つは、セキュリティ、プライバシー、信頼性が主要な差別化要因になると明言しています。 プライベート クラウド コンピューティング さらに、TLS などのプロトコルの現在の使用では、顧客が期待するエンドツーエンドのセキュリティとプライバシーの保証を提供できないことについても議論しています。 私は何年も前に、システム同士を接続する作業に携わっていました。これは、私のキャリアのごく初期の段階では、非常に手間のかかる作業でした。当社は成長を続けており、現在のビルのサーバー ルームを、新しいビルにインストールしたばかりのシステムに接続していました。新しいオフィスは通りから数ブロック離れたところにあり、私たちは地元の電話会社と協力して専用回線を設置していました。 当時、2 つの別々のネットワークを接続することは、明白かつ物理的に具体的な現実でした。 私たちは皆、その時代から進歩しました。現在、現代の技術スタックはより複雑になっています。相互接続された一連のアプリが世界中に広がり、クラウドで「最高の」製品企業によって実行されます。数十年にわたって、私たちは進化してきました。今日では、2 つの別々の企業が実際にネットワーク全体を相互に接続したいと考えることはまれです。通信する必要があるのは、各ネットワーク内の特定のアプリとワークロードです。 しかし、私たちはシステムを「安全に」接続する方法として、古いアプローチを使い続けています。 実際のケーブル配線は抽象化されていますが、実質的には同じことを行っています。これらの古いアプローチでは、無数のネットワークに推移的にさらされることになり、悪用される可能性の高い巨大な攻撃対象領域となります。 プライベートシステムへの接続の必要性 「クラウド」や「オンプレミス」という言葉が何を意味するのかは、過去数十年にわたって曖昧になってきました。混乱を避けるために、架空のシナリオを作成します。 これは、運用する SaaS プラットフォームです。これは、弾力性と拡張性を備え、大手クラウド プロバイダーの 1 つでホストされています。このプラットフォームは、多数の有用なメトリックの可視性を提供し、開発ワークフローに直接役立つフィードバックを提供するため、顧客は DevOps プロセスを改善するためにこのプラットフォームを購入します。 Initech プラットフォーム: これは、サポートしたい Initech の大規模な顧客です。さまざまな場所で多くのインフラストラクチャを運用しています。これは、自社のデータ センター内にあるという従来の意味での「オンプレミス」でしょうか。大手クラウド プロバイダーの 1 つにある自社の VPC 内でしょうか。どちらでも構いません。顧客のシステムは、Initech が制御していない、アクセスできない、パブリック インターネットから直接アクセスできない 1 つ以上のネットワークで実行されています。 ACME Corp: 開発者ワークフローへの積極的な関与 Initech プラットフォームの初期バージョンを構築する際には、製品と市場の適合性を証明するために協力できる潜在的な顧客が多数存在します。主要なバージョン管理システム プロバイダー (GitHub、GitLab、Bitbucket など) のパブリック API と統合し、コミット/Webhook を使用してイベントに反応し、結果をワークフローにプッシュし、すべてが期待どおりに機能します。 製品が受動的で、ACME Corp. の誰かが開始したイベントに単に反応するだけであれば、これは素晴らしいことです。多くのサービスは、世界の外部変化を評価し、顧客のために積極的に改善を推進することで価値を提供したいと考えています。 多くの依存関係やセキュリティ スキャン サービスについて考えてみましょう。新しい脆弱性が公開された場合、これらのサービスでは、影響を受けるすべてのリポジトリに対してできるだけ早く pull/merge リクエストを作成したいと考えています。パブリック API を備えた完全に管理された VCS サービスでは、これを実現する方法が提供されていますが、これらの製品のセルフホスト バージョンにはパブリックにアクセス可能な API がありません。 これらのシステムを自社でホストすることを選択する顧客は、通常、大企業に偏っているため、現在、私たちはいくつかの難しい決断に直面しています。Initech はこれらの高価値顧客に製品を販売できないのでしょうか? 顧客は、最も重要な機能の 1 つが欠落している製品の縮小版を購入する必要がありますか? それとも、Initech にアクセスを許可するために、セキュリティとネットワークの体制の一部を再評価するよう顧客に依頼するべきでしょうか? 個人データへのアクセス Initech は、カスタム レポート ソリューションを表示するためにデータベースをクエリする必要があります。これは Initech に固有の問題ではなく、ほぼすべての顧客データ プラットフォーム (CDP) または視覚化ツールに同じ問題があります。つまり、顧客はプライベート データをパブリック インターネットからアクセス可能にしたくないため、通常はプライベート サブネット内のデータベースに保存されます。 現在のアプローチの問題点 先ほど述べたように、現代の技術スタックは相互接続された一連のアプリへと進化しました。しかし、これらのアプリを接続する方法は、数十年前にネットワークを接続した方法からわずかに変化しただけです。これらのアプローチは便利で馴染み深いものですが、今日のユースケース向けに設計されたものではありません。 代わりに、彼らは、物事がかつて機能していた方法に可能な限り小さな調整を加えて、今日私たちが必要としている方法に近づけようとしています。 システムをパブリックインターネット上に公開する ほとんどのプライベート システムのデフォルトの展開オプションは、パブリック IP アドレスのないプライベート サブネットを持つプライベート ネットワークにシステムを配置することです。これには十分な理由があります。Initech がこのプライベート システムに接続する最も簡単なオプションは、インターネットからアクセスできるパブリック IP アドレスまたはホスト名を提供するよう ACME Corp に依頼することです。 これは悪いです。 最初にシステムを世界から切り離されたプライベート ネットワークに配置する理由はすべて、すぐに消えてしまいます。このシステムは、パブリック インターネット全体からアクセス可能になり、何千人ものハッカーが絶えず総当たり攻撃でシステムに侵入しようとしたり、単純に DoS 攻撃を仕掛けたりできるようになります。認証情報が 1 つでも漏洩したり、CVE やその他の問題が発生すると、すぐに攻撃を受けてしまいます。 リバースプロキシ もう 1 つのアプローチは、システムの前にリバース プロキシを配置することです。ここでは、nginx や HA プロキシのようなものについて話しているだけではありません。この説明に当てはまるホスト型またはマネージド サービスのカテゴリ全体も存在します。 これには、ACME Corp がプライベート システムをパブリック インターネットに直接置かなくなるという利点があります。リバース プロキシには、レート制限やアクセス制限の微調整機能も追加され、潜在的な DoS 攻撃を軽減します。これは多層防御の改善ですが、ACME Corp は依然としてパブリック インターネット全体からプロキシにアクセスして攻撃を試みることを許可しています。 侵害された場合、プロキシと同じように、トラフィックを目的の宛先に通過させます。 IP 許可リスト 漸進的な改善としては、Initech がリクエストの送信元となる IP のリストを提供し、ACME Corp にファイアウォールとルーティング ルールを管理させて、それらの IP アドレスからのリクエストのみを許可するという方法があります。ただし、これはあまり改善とは言えません。 Initech では、現在のアプリケーション インスタンスと IP アドレスを密接に結び付けることは望ましくありません。顧客に新しい IP アドレスを常に通知する必要なく、必要に応じてインフラストラクチャを拡張できる柔軟性が求められます。 したがって、IP アドレスは NAT ゲートウェイまたはプロキシ サーバーに属する可能性が高くなります。ACME Corp は、アクセスを 1 つまたは 2 つのソース IP アドレスのみにロックすると、1 つまたは 2 つのリモート マシンのみがネットワークにアクセスできると想定する可能性があります。 実際には、NAT ゲートウェイまたはプロキシ経由でリクエストを送信できるリモート ネットワーク上のすべてのものに、ACME Corp ネットワークへのアクセスも許可されることになります。これは、単一のアプリまたはマシンを許可するのではなく、リモート ネットワーク全体を許可することになります。 しかし、さらに懸念されるのは、IP ソース アドレスが れることです。潜在的な攻撃者は、適切な形式のリクエストを作成し、ソース アドレスを偽装して、ACME Corp ネットワークにデータや指示を送信することができます。Initech を含む SaaS ベンダーは、現在の IP アドレスのリストを文書化する必要があるため、偽装を試みる IP のリストがすぐに用意されます。 簡単に偽装さ IP フィルタリングのアプローチが洗練されればされるほど、それを侵害するためには攻撃者も洗練された技術が必要になりますが、完璧なものはありません。IP スプーフィングは、ほとんどの場合、攻撃者が応答を受信できず、何も役に立つことができないため、実際には DDoS 攻撃にのみ使用されると主張する人が過去にいました。 私たちが接続しているシステムについて考えてみましょう。貴重なデータを確実に作成/更新/破壊しない、ファイア アンド フォーゲット API 呼び出しがまったくないことに、どれだけ自信がありますか? 優れたセキュリティとは、データの漏洩を防ぐだけでなく、データを保護し、その整合性を保証することです。 あなたが大手金融機関などの貴重なターゲットである場合、攻撃者はこのようなアプローチを使用して 動機を持っています。顧客や見込み客が貴重なターゲットである場合、あなたも貴重なターゲットになります。 中間者攻撃を開始し、通信フローを傍受する 仮想プライベートネットワーク (VPN) VPN は、従業員がオフィス外から「企業ネットワーク」に接続できるようにするための、多くの企業で一般的なソリューションです。また、他のシステムを既存のネットワークに接続できるようにするためにも使用されます。 ここで取り上げるユースケースは異なります。2 つの別々の企業、つまり SaaS 製品とその顧客が相互に通信できるようにすることです。 こうしたケースの多くでは、接続の両端に相互に通信できるシステムが だけあります。代わりに、ネットワーク全体を接続するために設計されたツールを使用します。これは、ある会社のルーターから別の会社のルーターに仮想パッチ リード線を配線するようなものです。 1 つ もし私が、その物理的なバージョン、つまり、自社の生産環境から別の会社の生産環境に直接ケーブルを接続するように頼んだとしたら、おそらくあなたは少し躊躇するでしょう。かなり躊躇するでしょう。そして、それにはちゃんとした理由があります。しかし、VPN は「仮想」かつ「プライベート」であり、非常に簡単 (ケーブルを配線するのに比べて) で、非常に普及しているため、私たちはそれほど深く考えません。 各ネットワークで 1 つのものを接続するだけであれば、非常に正確な作業であるはずの作業に非常に鈍い器具を使用したことになります。 VPN を使用しても正確なタスクは実行できますが、各ネットワークで開きたいドアだけを閉ざすために、ネットワーク レベルの制御とルーティング ルールのレイヤーが確実に配置されている必要があります。これは、本来の目的にかなう優れたツールやアプローチがあるものの、進化したニーズに合わせてそれらを活用できるように、段階的に使用方法を変えていることを示すもう 1 つの例です。 それを安全に行うには、より複雑なレイヤーを重ね、それらのレイヤーのすべての詳細を常に正しく把握することを期待する必要があります。これを間違えると、当初の意図を超えた推移的アクセスのリスクが生じます。 ネットワークを信頼できない セキュリティ プログラムにどれだけの時間、人材、資金を投入しても、ネットワークは簡単に悪用されるセキュリティ ホールにほぼ確実にさらされているとしたらどう思いますか? … 業界データによると、世界最大規模の企業のうち、この新たな脅威から自社のネットワークを保護するための対策をまだ講じていない企業は 1% 未満です。 歴史は、正しいことをすることは最も簡単なことであると教えています。これはソフトウェア開発者にとって特に重要であり、意図的に悪意のあるコンポーネントから保護することが重要です。セキュリティ技術の採用曲線が緩やかなため、悪意のある行為者はその可能性に気づき、革新を起こし、サイバー犯罪の驚異的な成長を促進できました。 — 、ソナタイプ ミッチェル・ジョンソン これらのアプローチのそれぞれに問題となるのは、安全であると想定するには、多くの追加の想定が必要になることです。インターネット上では誰もあなたを危険にさらそうとしない、リクエストの送信元 IP は信頼できる、リモート ネットワークは善良なアクターのみで構成されている、これらの想定は現在も将来も無期限に当てはまり続ける、 そして、これらすべての想定は、あなたが接続したすべてのネットワーク、それらのネットワークが接続したすべてのネットワーク、そしてすべてのネットワークにも当てはまります... ACME Corp の観点からこれがどのように見えるかを見てみましょう。 今では、2 つのネットワークと 2 つの企業が相互に接続されている ではありません。多数のネットワークが接続されています。各 SaaS ベンダーは独自のサービス セットを使用しているため、さらに複雑になっています。ネットワークを信頼できないだけでなく、他のネットワークも信頼できません。この図の参加者は、ネットワークの設定ミスや依存関係の侵害によって、ネットワークを介してリスクを伝達する可能性があります。 だけ この図は、この問題のフラクタルの最も拡大された例です。縮小すると、各ベンダーは独自の顧客セット、独自のベンダー、独自の顧客と接続され、リスクの表面積は指数関数的に増加します。 さあ、解決しましょう！ わずか数分で、セキュリティを製品に機能として組み込むことができます。より焦点を絞ったきめ細かなソリューションを提供することで、セキュリティのレベルを引き上げます。また、ACME Corp などの顧客にネットワーク レベルの変更を依頼して、問題を押し付けることもなくなります。 代わりに、安全な接続をアプリケーション レベルの問題に移行し、Initech プラットフォームを必要な特定の場所に拡張することで、総合的な製品エクスペリエンスを提供します。 この例では、Initech Platform が ACME Corp によって管理されているセルフホスト型 GitHub Enterprise サーバーへの接続を確立する方法について説明します。最終結果は次のようになります。 必要なすべての部分を立ち上げるのに数分しかかかりません。その方法については、 をご覧ください。 セルフホスト型エージェントの基礎を構築するためのコード ツアー