フィーチャーフラグのセキュリティーに関する共通の質問

フィーチャーフラグは、セキュリティーやパフォーマンスのリスクではなく、実際に組織としてのセキュリティーとパフォーマンスの姿勢を向上させるものです。その方法をご紹介します。

運用やセキュリティーに関心のある人にとって、この世で最も恐ろしいことが２つあります。

1. あなたのコードベース内で依存関係として実行される必要があるコード。
2. 本番環境のユーザーエクスペリエンスが稼働時間に依存しているもの。

フィーチャーフラグは、概念としても、Harnessが販売する特定のソリューションとしても、入念な調査の対象となるのは当然のことです。この２つのベクトルにおいて、フィーチャーフラグはリスクをもたらすように見えるかもしれません。しかし、この記事では、フィーチャーフラグがセキュリティーやパフォーマンスのリスクではないこと、むしろ組織としてセキュリティーとパフォーマンスの姿勢を改善することを説明します。

話を進める前に、１つ注意点があります。この記事では、このブログで普段しているよりも具体的に製品としてのHarness Feature Flagsの側面を参照することにします。これは、当社製品だけを宣伝するためではなく、明確で具体的な説明をするためです。読んでいただければ、市場に出回っているほとんどのフィーチャーフラグ製品も同じように立派な仕事をしていることがお分かりいただけると思います。フィーチャーフラグというカテゴリー全体が、時間をかけて責任ある思慮深い進化を遂げてきたのですから。

顧客データ

フィーチャーフラグを使用する場合、SDKを介してサービスに公開される基準に基づいて、ユーザー、地域、またはテナントをターゲットにすることになります（詳細は後述します）。潜在的に利用される可能性のある情報の一部が、実際には機密情報であったりPIIポリシーに違反しているかもしれない、というリスクがあります。

このようなリスクがあるため、私たちは積極的にデータを収集しないという線引きをしています。共通のユーザーオブジェクトやフレームワークオブジェクトを探して自動的にHarnessに渡すことで簡略化の価値はあるかもしれませんが、顧客が明示的にデータを送信することを選択しない限り、データを収集したくありません。

そのため、フラグターゲティングに使用するデータを設定する際には、全てのデータを手動でコーディングして、お客様側で弊社に送信していただく必要があります。送らなければ、私たちには入手できません。

SDKs

SDKsは、フィーチャーフラグソリューションがどのように機能するかの核心となるものです。SDKをコードにインストールすると、SDKはアップストリームサービスと通信し、ターゲティングのためにユーザーまたはサーバーデータを送信し、提供される機能の状態を決定するルール設定を受信します。

これらのSDKはお客様のコードで実行されるため、私たち（そして私たちの業界でSDKを構築する他の全ての人）は、SDKを非常に慎重に扱います。既に述べたように、私たちのSDKは積極的にデータを収集したり、通信したりすることはありません。さらに、それらは全てオープンソースなので、いつでも完全に監査することができます。

各社とも、SDKの通信方法は若干異なりますが、１つか２つの類似したパターンを持っています。HarnessのSDKは、ストリーミングモードとポーリングモードの両方をサポートしています。ストリーミングモードは、サーバーから送られるイベントをHarnessからプロアクティブに受信し、リアルタイムのアップデートを提供します。ポーリングモードは、SDKが定期的に更新を取得し、継続的な接続を必要としないモードです。どちらも一般的に使用されています。

耐障害性 

よく聞かれる質問：Feature Flagsがアプリケーションの上流依存関係にないことを確認するには？Harnessがダウンしたら？Google CloudやAWSがダウンしていたら？特定のユーザーセッションで通信が非常に高いレイテンシーに見舞われたら？重要なのは、フィーチャーフラグによってユーザーが壊れたエクスペリエンスを目にすることはないということです。

フィーチャーフラグツールは、一般的にこのような懸念事項を全て考慮して設計されています。Harnessでは、お客様が安心してご利用いただけるよう、３つのレベルの耐障害性を備えています。

• SDK自体が評価をキャッシュする（サーバーsdksのルールもキャッシュする）ので、接続性に問題がある場合は常に第一レベルのフォールバックを持つことになります。
• コードにフラグを実装する場合、キャッシュがなく、かつ接続性がない場合に使用されるデフォルトを常にハードコードすることになります。
• また、Harnessとアプリケーションの間で実行可能なリレープロキシーも提供しています。これは完全なキャッシュを提供し、Harnessへの接続を制限し（プロキシーのみがHarnessと話す必要があります）、サイドロードすることも可能です。

これらを組み合わせれば、フィーチャーフラグサービスへの影響によりアプリケーションが解決できない事態は発生しませんし、上流のHarnessにアクセスできない場合はプロキシーがサイドロードされるため、ミッションクリティカルなフラグを変更できない事態も発生しないのです。

助ける、傷つけない

このように、フラグソリューションは、不注意によるリスクを認識した上で設計されています。OSS SDK、キャッシュ、プロキシー、コード内デフォルトなど、これらのリスクは慎重に対処されているため、安心してフラグを立てることができます。

そのため、フィーチャーフラグをリスクとしてではなく、セキュリティーと信頼性の重要な一部として考える価値があります。

• あらゆる変更に対して、ロールバックを必要としないインスタントキルスイッチを本番環境に導入。
• 全ての変更の監査ログ
• 誰がどのように変更できるかを管理する、堅牢なガバナンスと権限管理。

もう、開発者や運用担当者がリソース上で直接プレイブックを実行する必要はありません。フラグを使用して、重要なプロセスを可視化し、繰り返し使用できるようにします。

まとめ

セキュリティーとパフォーマンスのためにフィーチャーフラグがどのように構築されるのか、その詳細について知るべきことはもっとたくさんあるのです。これは概要を説明するためのものに過ぎません。しかし、フィーチャーフラグがあなたのアプリケーションをより安全でより高性能にし、リスクを導入する可能性をサービスから排除することを保証するために、どの程度の注意が払われているかがお分かりいただけると幸いです。

より詳細な情報については、いつでも私たちのドキュメントを参照するか、私たちに質問を送ることができます。セキュリティー、アーキテクチャー、パフォーマンスに関するご質問にも喜んでお答えします。

この記事はHarness社のウェブサイトで公開されているものをDigital Stacksが日本語に訳したものです。無断複製を禁じます。原文はこちらです。