2023 年にセキュリティを維持する方法

公開: 2023-04-09

セキュリティとパフォーマンスは、開発するすべてのプロジェクト、サイト、アプリ、およびコンポーネントの基礎です。しかし、この絶え間なく変化する状況では、基本的なベストプラクティスを常に把握しつつ、革新することは困難な場合があります。

この対談では、2023 年にセキュリティとパフォーマンスをどのように維持しているかについて、一流の技術者から聞いてください。

ビデオ: 2023 年にセキュリティを維持する方法

スピーカー:

WP Engine の SVP 兼最高技術責任者である Ramadass Prabhakar 氏は、次のように述べています。
ローレンス・エドモンドソン、バーバリアンの CTO
Sergi Isasi 氏、VP Product、Cloudflare のアプリケーションパフォーマンス
Tim Nash、timnash.co.uk の WordPress セキュリティコンサルタント
space150 の CTO である Jimmy Squires 氏

転写:

ラマダス: 皆さん、こんにちは。 Decode の第 4 版へようこそ。毎年参加者が増えているのは素晴らしいことです。過去数年間で、業界全体のセキュリティ環境に大きな変化がありました。セキュリティ違反やセキュリティに関する定期的なニュース速報は、顧客や開発者との議論で頻繁に取り上げられるトピックとして見られます。そこで本日、私たちはセキュリティに情熱を傾け、私たちの質問に答え、学んだことを私たちと共有するためにここにいる素晴らしい業界専門家のグループを集めました. それでは、パネリストの簡単な紹介から始めましょう。ローレンス、あなたに。

ローレンス・エドモンドソン: お越しいただきありがとうございます。 Barbarian の CTO、Lawrence Edmondson です。 Barbarian はフルサービスのデジタルエージェンシーです。私たちはニューヨークにいます。

ラマダス: ありがとう、ローレンス。あなたに、セルジ。

SERGI ISASI: ありがとう。私は Cloudflare の製品担当副社長です。 Cloudflare では、WPE などの顧客やパートナーがインターネットに安全かつ高速に接続できるようにする製品を構築しています。私はサンフランシスコにいます。

モデレーター: ありがとう、セルジ。そして、ティム、あなたに。

TIM NASH: 私はここ英国で WordPress セキュリティコンサルタントをしています。そして、私は基本的に開発者を怖がらせることに人生を費やしています。

モデレーター: ありがとうございます。そしてジミー。

ジミー・スクワイアーズ: ええ、ありがとう。 Space 150 もミネアポリスのフルサービスデジタルエージェンシーで CTO です。

モデレーター: 本日は、私たちのパネルに参加していただきありがとうございます。では、組織内またはチーム内で現在セキュリティに関して行っているユニークなことについてお話しすることから始めたいと思います。それでは、セルジから始めましょう。

SERGI ISASI: ええ、開発者を怖がらせるティムのイントロを再生します。私たちが Cloudflare でもっとやろうとしていることの 1 つは、顧客にトラフィックに関するより多くの洞察を提供し、運用上の負担を軽減することです。歴史的に、ネットワークに影響を与えている可能性のあるもの、目にしている可能性のある攻撃を見つけたい場合は、WAF を展開し、それをログモードにしてから、セキュリティアナリストにログを見てもらい、それが検出したものを参照してください。そして、最近ではそれを行うためのリソースがはるかに少なくなっています。

そのため、今年の焦点は、お客様が現在その攻撃を防ぐ製品を使用していない場合でも、お客様に見られる攻撃についての洞察を提供することです. そのため、アプリケーションが攻撃を受けているかどうか、または一般的に良好な状態にあるかどうかを知ることができます。そして、それが今年の残りの期間の焦点であり、すべてのセキュリティ製品を紹介し、ネットワークで何が起こっているのか、実際に何が起こっているのか、そしてそれをブロックしたいかどうかをお客様に知らせます.

モデレーター: すばらしい。それは実際には非常に強力に聞こえます。それについてもっと聞くのを楽しみにしています。それでティム、あなた自身はどうですか？

TIM NASH: 私は、両方のエージェンシーだけでなく、小規模な個々の Web サイトなど、さまざまなクライアントと仕事をしています。また、コードレビューやサイトレビューも数多く行っています。そして、今年まで、レビューをもらって、言われた仕事をするだけで満足するほど、実際に気にかけてくれる人が増えたのを見たことがありません。したがって、彼らにたくさんの推奨事項を与えると、彼らはただ従います。しかし、翌年にサイトに戻ってきたら、別の推奨事項を提供しているだけです. ですから、私はこの昨年、実際に質問をするのに十分なほど気を配っている人々の変化を非常に多く見てきました. そのため、私にとっては、コード監査は大きくて長いこのファイルの 6、4、2 行目で破棄されました。何とか、このように実行する必要があります。

私はそれをすべて取り除き、本当に教育に集中し始めました。正直に言うと、ほとんどの人が望んでいるのは、「この行を修正しなければならない」と言われることではなく、「修正する方法は次のとおりです」と言われることであることに気付きました。そこに沿っているすべての行。だから私にとって、大きな変化と大きな焦点の変化は教育に向けられました。そして、これは業界全体のことです。今年はセキュリティについて話す人が昨年よりも増え、昨年よりも増えていると思います。

モデレーター: いいえ、それは素晴らしいことです。魚を与えることから、魚の捕まえ方を教えることへと焦点を移すという点が本当に好きです。それは本当に-

ティム・ナッシュ: 私は決まり文句であるために、その例えをどうしても避けようとしていました。

モデレーター: ありがとうございます。

TIM NASH: よくできました。

モデレーター: わかりました、ジミー。

JIMMY SQUIRES: ええ、たくさんあると思います。この回答について話すために、ある特定のことに焦点を当てることにしました。そして、API トークンとアクセスを扱うとき、それは実際にスコープを制限しています。昨年の Heroku と GitHub リポジトリの侵害は、非常に多くのことしか制御できないことを思い出させてくれました。そのため、開発者と協力するときは、使用しているプラットフォームやシステムに関係なく、範囲指定されたアクセスポリシーの重要性を思い出させます。多くの場合、開発者は、開発の早い段階で簡単にアクセスできるようにしたいと考えています。そして、私たちがおそらく認めていることは、恥ずべきことですが、生産前にあるべきレベルまで引き締められていないことがあります。そのため、これらのセキュリティスコープを実際に考慮して、早期に開始します。

モデレーター: ありがとう、ジミー。そしてローレンス、あなたも開発者と多くの仕事をしていることを知っています。それで、あなたはそのためにその前に何を見ていますか？

ローレンス・エドモンドソン: そうですね。確かに、ジミーが言ったことに基づいて構築するために、私たちは両方とも広告の仕事をしています. ですから、広告業界で働く場合と製品環境で働く場合とでは、同じ課題がたくさん見られると思います。私たちにとって、私たちはさまざまなテクノロジー、さまざまなテクノロジースタックに触れています。私たちは技術的に不可知論者でなければなりません。つまり、消費者はモバイルやソーシャルを通じてさまざまな方法で関与していることがわかります。数年前、デスクトップはサイトやコンテンツにアクセスするための主要な手段でした。これで完全にひっくり返った。デスクトップからモバイル、そしてソーシャルへと移行しました。

したがって、API レイヤーとアプリケーションレイヤーは、健全なパラノイアが少し関連付けられるような方法でロックダウンする必要があります。私たちが見ているのは、攻撃範囲が拡大していることです。そのため、DevOps がプログラマーのように考えて、物事が侵害される可能性のある方法を理解できるようにする新しい方法を常に模索しています。それが今日私たちがやっていることのようなものです。

モデレーター: ありがとうございます。そして、攻撃ベクトルがどのように増加しているかについておっしゃいました。そして、それは私たちがここWP Engineで持っているものであり、多層防御メカニズムをどのように採用するかについてもっと調べてきました. したがって、どの層も安全であると信頼しないでください。では、それをどのようにコーディングの方法やソフトウェアの作成方法に組み込むのでしょうか。それでは、よろしくお願いいたします。皆さんがそこで起こっているトレンドの変化について話していたように、この 1 年間に発生した違反です。 2023 年に向けて、皆さんが注目している主要なテーマや脅威は何ですか? そして多分、セルジ、あなたは私たちを始めることができます. うん。

SERGI ISASI: わかりました。これはばかげているように聞こえるかもしれませんが、それは 2023 年であり、私は DDOS という言葉を口にするつもりですが、それでも問題ではありません。そして、DDOS の世界では、この 9、12 か月で本当に興味深い変化がありました。ボリューメトリックは、最近の DDOS ベクトルではあまりありません。反射がかなり少ないです。また、脅威アクターの観点から見ると、既製のツールがたくさんあるので、DDOS を起動するのは簡単ですよね? もうすぐスクリプト TD の時代に戻りますが、侵害されたシステムを攻撃することも少なくなります。したがって、リフレクションを行おうとしている場合、システムにパッチを適用していない可能性のある人によって管理されているインフラストラクチャは多くないため、1 つのパケットを取得して 10 に変えることができます。それはもはや大したことではありません。

そのため、彼らはレイヤー 7 に移行しています。レイヤー 7 は、実行に多くの CPU が必要なため、起動にコストがかかりますが、緩和にもはるかにコストがかかります。したがって、ある種の DDOS 保護システムを使用している場合は、実際に接続を受け入れ、それを調べてから、下位層でドロップできるものと比較して、ドロップを開始する必要があります。私たちが発見したことと、先月報告された最大のレイヤー 7 DDOS を軽減しました。これらの攻撃の大きなテーマは、より強力なデバイスです。

したがって、最近私たちが自宅でプラグインしているすべてのものについて考えると、そのデバイスのプロセッサは、3、4 年前よりもはるかに優れています. だからあなたのカメラはもっと多くのことをします。そのため、より強力な CPU が搭載されており、ルーターでさえ実際にはかなり強力なマシンです。また、これらのデバイスが侵害されると、大規模な攻撃が可能になる可能性があります。特に、1 つを侵害すると、基本的に接続されているすべてのデバイスが侵害されることになります。

最近話題になっているもう 1 つのことですが、もう少し静かなのは、侵害されたハードウェアデバイスからクラウドサービスの侵害されたアカウントに移行したことです。クラウドサービスの CPU は事実上無制限です。したがって、多数の個人または企業のアカウントにアクセスして、そのクラウドシステムで必要なものを起動できれば、非常に大規模な攻撃を仕掛けることができます。そして、それが記録破りの攻撃で私たちが目にしていることです。ええ、2023年、まだDDOS、まだありますが、現在はレイヤー7対下位レイヤーです.

モデレーター: ありがとうございます。これは恐ろしいことですが、同時に、セキュリティプロトコルをどのように強化し続け、重点分野が拡大し続けているかを示していると思います。ローレンスさん、あなたと私は過去に AI がブームであると同時に脅威でもあると話していました。ジェネレーティブ AI に関するあなたの考えと、それが 2023 年のセキュリティの表面領域に実際にどのように影響するかについてお聞きしたいと思います.

LAWRENCE EDMONDSON: 私は非常に興奮しており、AI に対して非常に強気です。私たちはバーバリアンにいますが、同時にとても怖いです。 chatGPT のようなものが悪意のある方法で使用される可能性。たとえば、Chat GPT でコードにコメントを付けることができます。そして、それは実際にはかなりまともな仕事をします.どの言語とコードがどれほど乱雑であるかにもよりますが、かなり良い仕事をします. 次はChat GPTについてだと思いますが、これはすでに進行中かもしれません.Chat GPTは毎日のようにこれを行っているからです. 今日のように、Slack で応答し、Slack で回答を見つけることができることを確認しました。

したがって、セキュリティの観点から、Chat GPT の次のことは、Chat GPT にエクスプロイトを見つけさせ、実際にコードを書き込むことだと思います。悪意のあるコードは、見つけた弱点を実際に悪用します。ですから、特にメモリ内での可能性が見られます。したがって、メモリ攻撃は常に署名を残すわけではありません。そのため、従来のウイルスやウイルススキャナーは、攻撃のシグネチャを探すことに取り組んでいます。メモリ攻撃では、アプリケーションを攻撃しています。バッファオーバーフローのようなことをしています。実行時にアプリケーションを侵害しようとしています。 Chat GPTは実際にそれを行う準備ができていると思います。そして、最初の大規模な ChatGPT エクスプロイトが発生するのを見るのは時間の問題だと思います。

ティム・ナッシュ: それが実際にどのように起こると思いますか? 明らかに、ChatGPT は、その中心にあるのは、サーバーへの一連の API リクエストにすぎません。そして、悪意のあるコードを生成するという要求を送信しています。それを元に戻すことです。つまり、すでに悪意のあるコードを生成している人がたくさんいます。では、既存の悪意のあるコードよりもさらに悪いコードを作成するにはどうすればよいでしょうか?

ローレンス・エドモンドソン: その通りです。学ぶべき大規模なリポジトリがすでにあります。つまり、ChatGPT が何をするか、実際に見て、モデルをトレーニングする必要があります。そのため、エンジニアは時間をかけてモデルをトレーニングし、誰かがこれを言ったときに、これが実際の意味であることを認識できるようにします。したがって、コンテキストを理解してください。まさにそのとおりですが、方法が異なります。実際にコードを記述し、それが実際に何を意味するかをモデルにトレーニングします。また、一部の言語は非常に簡単です。だからPHP、PHPでコードを書くのはとても簡単です。これらのインタープリター言語は、はるかに簡単です。これはかなり厄介ですが、コンパイルが必要な Java のようなものを実行するのとは対照的に、私の言いたいことがわかりますか?

簡単な方法は、chatGPT 3 に基づいてモデルを作成し、それを実際にトレーニングすることだと思います。構文を理解して、基本的なコンピューターサイエンスのすべてを理解してから、それを取得します。ステップアップして、OK、これらの NPM パッケージにはこれらのエクスプロイトがあります。それを探して、実際の方法を考え出してください。彼らにはこれらの脆弱性があります。申し訳ありませんが、それらの脆弱性を悪用する方法を検討してください。私はそれを保証します、私たちはそのようなことが起こるのを見るのにそれほど遠くない.

モデレーター: ありがとう、ローレンス。非常に新しい分野だと思います。この分野で興味深いのは、AI の場合、一般的に、これらのシグネチャを実際に使用して防止し、AI から学習して、どのように私たちを防止できるかを確認するために、AI を活用できることのバランスが取れていることです。貧弱なコードまたは脆弱なコードを書く。同時に、人々が話しているのを見たのと同じように、チャット GPT を使用して最初のプラグインを 5 分で作成しました。これは、人々がマルウェアを少し作成できるようになるということではないかと思います。もっと早く？しかし、それは両方の側面を持っていると思います。

これらのツールを引き続きどのように活用して、コードの記述を改善するか、より安全なコードを記述するかが重要です。ティム、それはあなたが情熱を注いでいる分野だと私は知っています。 2023 年にセキュアコードがどのように進化するか、またその分野で何を行っているかについて、もう少しお話しいただけますか?

TIM NASH: つまり、多くの点で、Chat GPT はその良い例です。私が攻撃ベクトルについて考えていたとしたら、正直に言うと、それが大量スキャンを実行し、悪役として多くのものを供給しているとは考えていませんでした。私はそれを、時間を節約しようとして、Chat GPT に何かをフィードし、それを捨てていて、書かれている、生成されているすべてのコードを完全に理解しているとは限らず、テストを書いていない平均的なコード開発者だと考えていました。それと一緒に行きます。これは簡単なことです。簡単なスクリプトです。問題ありません。生産に入りますが、うまくいかず、すべてが燃えています。

現在、これはすべての開発者が毎日行っていることとまったく同じです。チャット GPT はそれを変更していませんが、わずかに簡単に有効にできます。それは与えます–障壁が少なくなります。

SERGI ISASI: ええ、スタックオーバーフローなどからのコピーアンドペーストとはまったく同じではありません。ティム、これは基本的に私がコードに対して行っていることのすべてです。でも、プラスにもマイナスにも確実に効率が上がっていると思います。しかし、これにより、より微妙な変更が可能になり、署名ベースのエンジンが追いつかないようなものをより迅速に利用できるようになると思います。したがって、実際に検出を行うときは、過去に見たものと直接一致させるのではなく、これが過去に見たものと似ているかどうかを判断するシステムが必要です。そして、それは実際には検出側でもあり、ML や AI、またはあなたがそれを何と呼びたいかでおそらく最もよく機能します。

基本的にボットの自動化されたトラフィックでそれを学びました。署名ベースの検出をどのように回避しているかを知る最良の方法は、ML を使用することです。しかし、あなたは今、これが悪いことであることは完全にわかっていますが、自動化される可能性が高いか、以前に見た署名のように見える可能性がありますが、完全に一致するわけではありません。

モデレーター: すばらしい。ありがとう。その追加のコンテキストについて、Sergi と Tim に感謝します。出席者の中には、今日ここにいる多くの開発者や代理店がいます。また、特に脅威ベクトルの観点からシナリオが変化しているため、多くの人がベストプラクティスの確立について考えています。サイト、アプリ、またはプラットフォームを構築するとき、または新しいプロジェクトを開始するときに推奨されるベストプラクティスは何ですか。では、人々が気をつけなければならないことにはどのようなものがあるでしょうか。

SERGI ISASI: それでは始めましょう。開発側というよりは運用側になります。私たちがここで説教していることの 1 つは、何か悪いことが起こると仮定することだと思います。つまり、侵害が近づいているということです。それに驚くだけではいけません。それはある時点で起こる可能性があります。そして、私たちの鍵となるのは、そのためのランブックを作成することです。そのため、問題が発生した場合は、検出と対応の両方から、どの個人に連絡すればよいか、どのような対応をするかを知っておく必要があります。そのために、私たちがCloudflareでうまくやっていると思います.Cloudflareは私たちのブランドの一部であり、それが私たちに非常に役立ったと思います.が起きた。

オープンであることは、何かが発生したときに顧客との信頼を再確立するための非常に重要な鍵となってきました。それがソフトウェアの侵害であろうと、インシデントに関して何かミスを犯したことであろうとです。その後ろに隠れることは決して正しい呼びかけではありません。

モデレーター: はい。

JIMMY SQUIRES: 他にも何かあると思います。誰もが明らかにリモートであり、特に開発チームは、実際にプロジェクトの開始時にホワイトボード作成とアーキテクチャ計画を行うために時間を割いています。要件に飛び込んで開発ストーリーを書き出すのはとても簡単ですが、同僚と一緒に時間を費やして、これをどのように悪用できるかを考えてみませんか? シナリオを実行します。私たちは、アプリケーションのさまざまな部分をどのように強化したいかなど、多くの良い会話につながる多くのシナリオ計画を立てています。

LAWRENCE EDMONDSON: それだけで、誰かが知っているかどうかはわかりませんが、MPM は実際には共有の最大のリポジトリです。アプリケーションライブラリの単一の最大のリポジトリですが、それは最大のリスクももたらすことを意味します。したがって、NPM を使用している場合に新しいプロジェクトに着手するときに非常に認識していることの 1 つは、脆弱性を調べていること、製品にプッシュするバージョンをロックしていることを確認することです。アップデートを行っていますが、互換性があるだけでなく、非常に安全なものであることを確認しています. 多くの脆弱性が NPM を介して忍び寄るのを見てきたため、未解決の脅威はありません。そのため、注意すべき点は 1 つだけです。

ティム・ナッシュ: ぐるぐる回っていると思います。

ジミー・スクワイア: どうぞ、ティム。

TIM NASH: 何年にもわたる開発サイクルの中で、実際には信頼が完全に壊れているという考えに、これをループさせていると思います。人々は今、それに気づき始めています。たとえば、WordPress で作業している PHP 開発者は、そこに座ってアクションとフィルターを呼び出しますが、それらのアクションとフィルターを信頼するべきではありません。入ってくるデータはすべて、検証し、チェックする必要があります。消毒する必要があります。しかし、それがデータベースから出てくるとき、あなたはまだそれを信頼すべきではありません.

そのデータをデータベースに入れたとしても、出てくるデータを信頼すべきではありません。 NPM であれ、composer パッケージであれ、別の WordPress プラグインであれ、サードパーティのライブラリに何かを渡している場合、すぐにそれは私たちの管理下に置かれ、二度と信頼することはありません。しかし、戻ってくると、確認したとしても、まだ信頼できません。そして、開発者として、すべてのデータは信頼されるべきではなく、完全に分離されるべきであり、あらゆる時点でセキュリティチェックを行うべきであるという考え方を持っていれば、あなたは出てくるでしょう.より安全なシステムで。少し遅いシステムで出てくるかもしれません。少しイライラするシステムや、実際に行っていることが助けになる以上の問題を引き起こしていないことを確認するために、さらに多くのテストが必要なシステムに遭遇するかもしれません。

モデレーター: ええ。

TIM NASH: 複雑さは増しますが、最終的にははるかに安全なシステムになります。そして、ほとんどの人にとって、それが彼らの望みです。

ローレンス・エドモンドソン: ええ。

モデレーター: ええ。あなたは絶対に正しいです。通過する他のコードを信用しないということです。 Jimmy と Sergi が話していたことは、アーキテクチャの観点から、または運用の観点から計画を立てることですが、セキュリティで保護されたコーディングメカニズムのようなものであろうと、インシデントプレイブックを持つことであろうと、それらすべてを全体的なプラクティスにまとめることです。ですから、ティム、私はあなたの周りからもっと話を聞くことに非常に興味があります.あなたは世界中で多くのトレーニングを行い、多くの教育を行っています. 人々がプロジェクトに取り組み始めるときに目にするよくある間違い、またはあなたが犯した可能性のある間違いは何ですか?私はそれらの多くを犯しました.

ティム・ナッシュ: 私が言おうとしていたのは、私が話そうとしているすべての過ちについて、私は間違いなく有罪であるということです。そして、最大かつ最も単純なものは、いい人になることです。ほとんどの開発者は善意を前提としています。ほとんどの人は、アプリケーションを作成した方法でアプリケーションを使用すると想定しています。現在、ドキュメントを作成していないため、ユーザーはそもそもアプリケーションの使用方法がわからないことがよくありますが、それは別の問題です。悪いアクターが入ってきて、バグを取って去っていきます。それはバグではありません。悪いアクターにとって、それは機能です。それはチャンスです。開発者が予期していないことを行っているため、潜在的なルートがあります。

そして全体として、ユニットテストのセットがあると言うと、何度も目にするものです。それはいい。しかし、あなたはポジティブなこと、あなたが望んでいた結果をテストしただけです。これらの境界の外に出るとどうなるかをテストしていません。上司の要求どおりに機能することを確認するためのテストが完了しました。つまり、実際にあるのは受け入れテスト、疑わしい受け入れテストです。そして、すべての基本に戻ります。開発者として、これに裏打ちされています。物事を信頼しないでください。特に WordPress 開発者の場合、WordPress には、私たちが人々に要求するあらゆる種類の標準的なセキュリティ作業を実行するための非常に優れたヘルパー関数が実際にいくつか備わっています。

そして、それらを使用するための教育と学習についてです。コードレビューをしていると、何度も同じ問題に遭遇します。コードの一部で 1 回見れば、同じコードセットで 1,000 回見られます。そして、それは、ええと、古いものをページに表示できるようにしただけです。そこに何かが入っているかどうかをわざわざチェックしませんでした。ええ、私たちはデータベースに物を入れました。おっと、SQL クエリのように見えるかもしれませんが、そうではないかもしれません。

これらの種類のものはすべて簡単に修正でき、修正するためのツールは既に提供されています。そして、私たちがそれらを修正しない理由は、多くの場合、これらのことを起こしてはならないことを人々が知らないということでさえありません。それは単に私たちが怠け者になり、物事をすばやく実行し、スタックオーバーフローからコードを取得しているからです。私たちは Chat GPT に何かをしてもらっていますが、物事をチェックしているわけではありません。そして、この状態から多くのセキュリティ問題が発生します。急がなければなりません。急がなければなりません。私は急がなければなりません、私はこれを成し遂げなければなりません。私は次のことに進みます、私は次のことに進みます。

非常に奇妙なことに、多くの開発者にとって、実際には時間とスペースを与えて、自分が行ったことを実際に確認するのに時間がかかっても問題ないと言っているだけです。私は戻ってきて、まあ、これらすべてと開発者はおかしくなっていると言っています。彼らは行きます、ええ、私たちはこれをすべて知っています。時間がありませんでした。

うまくいけば、人々により多くの時間を与え、実際にツールを実際に提供することができます。これは、特に WordPress 内で既に入手しています。 WordPress には、WordPress プラグインまたはテーマで発生する最も一般的なセキュリティ問題に対する非常に優れたヘルパー関数のセットがあります。つまり、それらを学び、実際にそれらを実装するために時間を費やすだけです。

モデレーター: ええ。そして、それは本当に強力だと思います。時間を投資してください。ほとんどの場合、開発者は何を修正する必要があるかを知っています。だから彼らに時間を与える。だから私はそのメッセージが本当に好きです。そしてジミー、あなたがこれをエージェンシーのワークフローに取り入れたことは知っています。あなたが実装した安全なワークフロープラクティスについてもう少し話したいですか?

JIMMY SQUIRES: ええ、絶対に。そして実際には、Sergi が言った計画を立てることから始まります。実際には、開発チームが従うべきガイドラインと標準があります。非常に基本的なことのように聞こえるかもしれませんが、私は多くの組織を見てきましたし、何年にもわたって採用してきた多くのエンジニアから、それは存在しなかったと聞いています。彼らの出身地には組織がありませんでした。

そのため、私たちがやりたいことは、標準的な一連のガイドラインを用意することです。新しいエンジニアは全員、それを上から下まで読む必要があります。消耗品ではないほどの重さではありません。マークダウンで保存したいので、すべてリポジトリに入れます。おそらく、ある時点で実際にオープンソース化するでしょう。そこには本当に独占的なものは何もありません。それはすべてのエンジニアへのお願いです。

したがって、私たちのガイドラインでも、追加できるところ、改善できるところに穴を開け、それを継続的に増やしていきます。しかし、OWASP のような基本的なことのいくつかに時間を費やすことは、非常に古い慣行ですが、それらのことを考慮して、アプリケーションでそれを実行します。それはティムが言ったことのようなもので、本当に時間がかかり、それに時間をかけても大丈夫です. AI の会話にもう 1 つポイントを追加したかったのです。先週、エンジニアの何人かと話すと、実際にイベントがありました。これは、私たちが Chat GPT を実際に単体テストに使用しているものです。関数を取り上げて興味深い方法で探索します。Chat GPT のようなものを活用して、その単体テストの最高の作成者ではない単体テストを作成するにはどうすればよいでしょうか。Tim の要点です。それが、予防的な方法でAIをもっと活用できる場所だと私が考えるところです.

ローレンス・エドモンドソン: ええ。私たちが私たちの側で行っていることは、チェックリストとプレイブックを持つことは素晴らしいことだと思います. 私たちは SonarQube などの自動化ツールを使用しており、実際に lint を実装しています。lint でコードの品質を向上させるためだけでなく、SonarQube を使用して、コードがより安全であることを確認しています。脆弱性などのために。前述したように、言語の性質上、一部の言語は他の言語よりもエクスプロイトを見つけやすいと思います。また、特定のフレームワークでは、そのコードベースに貢献しているコーダーの質が一般的です。これは通常、オープンソースでよく見られます。スタックオーバーフローのコピーアンドペーストが大量に行われているのに対し、実際に研究した人々とは対照的です。 CSであり、彼らが何をしているかを本当に知っています。だから、それは私が見た 1 つのことです。

TIM NASH: 確かに私自身、ほぼ毎日 Stack OverFlow を使用していることを指摘しておく必要があると思います。そして、私たちは皆それに対して有罪です。それを手がかりにするのは良いことですが、そうは思いません。つまり、最初にコーディングを始めたときのことを覚えています。私は雑誌を手に入れ、雑誌からコードを入力して Enter を押していました。スタックオーバーフローなどの機能がなかったら、今日の Web が実際に機能しているとは想像できません。

Sergi: いいえ、促進剤です。そしてうまくいけば、AI はその次の段階です。しかし、ええ、それは楽しいミームです。

モデレーター: ありがとうございます。ということで少しシフト。業界では、ヘッドレスとヘッドレスの実装に関して多くの機運が高まっています。また、今日の他のチャンネルや他のセッションでも、ヘッドレスについて話しているのを見ました。そのため、WP Engine で Atlas を使い始めたとき、多くの開発者と会いましたが、セキュリティは常に重要な動機でした。では、ヘッドレスのセキュリティをどのように見ていますか? そして、ジミー、これはあなたがいくつかのプロジェクトを行ってきた分野です。ご意見をお待ちしております。

JIMMY SQUIRES: ええ、私たちはヘッドレスで多くの仕事をしています。現時点では、ほぼすべてのプロジェクトがおそらくヘッドレスアーキテクチャアプローチを採用していると思います。セキュリティに関連するので、いくつかの点を指摘したいと思います。 1 つ目は、ヘッドレスアーキテクチャを選択する場合、通常、最初はオープンソースキャンプに身を置いているということです。もちろん、オープンソースとクローズドソースのどちらがより安全かについては、多くの議論があります。私は、OSS プロジェクトの方が本質的に安全であるという陣営に陥りがちです。つまり、巨大なコミュニティを持つ Next や WordPress のようなフレームワークを選択しているのです。そして、それは露出だけでより多くのセキュリティに役立つ傾向があります.

だから一つだと思います。 2 つ目は Static Generation のようなものだと思います。そのため、多くの Web サイトや製品が構築されているため、大規模なコンテンツ管理の動的な性質、従来の意味でのモノリシックシステムは必要ありません。 Cloudflare のようなものを活用して、そのアプリケーションの大部分を実際に静的に生成できるため、ベクターと露出のフットプリントを削減できます。だから私たちはそれの大ファンです。もちろん、それによってすべてのパフォーマンス上の利点も得られます。これらは、ヘッドレスアーキテクチャについて私が伝えたかったポイントのほんの一部です。しかし、セキュリティの観点から、私たちがそれを気に入っている理由は他にもたくさんあります。しかし、それらはおそらく最大の傑出した領域の2つであると思います.

ティム・ナッシュ: レールに戻って、まだコンテンツ管理システムが背後にあることを人々に思い出してもらいたいと思います。そして、ヘッドレスは完全に安全だとよく耳にします。ええ、しかし、ウェブサイトから直接呼び出していないという理由だけで、まだそこにある公開されたWordPressインスタンスは、ええ、まだadmin.yoursite.comにあります。そして、あなたはそうではありません-そうそう、まあ、私たちは今安全なので、ウェブサイトではないので最新の状態に保つことを心配する必要はないという特定の信念があります. いいえ、いいえ、以前に行っていたすべてのことがまだ必要であり、今では反対側も取得しています。

つまり、ヘッドレスは長い間存在し、勢いを増しているものを表す素晴らしい用語ですが、WordPress に REST API が導入される前からこれを行っていました。 WordPress からコンテンツを Jekyll などにプッシュして、少なくとも静的なサイトを取得していました。そして、それを行う元の理由は、WordPress システムまたはネットワーク内のコンテンツ管理システムを変更することでした. だから、あなたはそれをロックダウンして、大きくて恐ろしいウェブから遠ざけることができます.

現在、ヘッドレスソリューションを提供しているホスティング会社を多数獲得しています。そして、そのインフラストラクチャが再びクラウドに移行しました。 So we've sort of moved the big benefit for Headless. And we're slowly shifting it back into the public domain again, which seems like a very almost backwards move, but it's the only move for widespread adoption. So there's a balancing act we have there. But yeah, just a small little warning into the big space of keep the backend secure still. You can't just rely on it being–

TIM NASH: Just because something's got some HTML files at the front, the back end still needs to stay just as secure as before.

MODERATOR: Yeah, absolutely. I mean, Headless, by default, doesn't mean that everything is secure. It means that you have a different paradigm. And that's what I think I was interested in, looking at what practices that you bring in as you look at Headless infringers. So yeah, I think that's you're very apt in stating that you still have to secure both the CMS part, as well as the web part of it. So as we are wrapping up, what I would love to do is we have had a lot of good topics to talk about in here, but I would love to take like 10 seconds from each one of you to say that if there is one thing that our audience could do in these next two months after the end of the session, what would that be? What's your recommendation?

LAWRENCE EDMONDSON: I guess I'll start off. My recommendation would be very simple. Security should be everyone's business. I think a lot of times, security doesn't become a topic or consideration until there's a problem. If I were a developer, I would make sure that I am being very proactive in terms of taking the necessary steps. It's 2023, we shouldn't be storing anything in clear text.

Everything should be encrypted as much as you can. Use Hashicorp, encrypt your database and make sure that your keys are stored securely, or it's something that's not easily compromised. But that's what I would encourage folks to make sure that security is top of mind all the way throughout.

MODERATOR: Thank you, Lawrence. Sergi, what about you?

SERGIS ISASI: I would say get an inventory of what's exposed. Know what's on the internet and make sure that the proper– at least aware of what's there, if not fully protecting it.

MODERATOR: Thank you. And Jimmy?

JIMMY: Scenario planning. Take the time in your project to do the scenario planning and create those playbooks, both preventative and then reactive once something does happen, to Sergi's point earlier. What are your action steps for that? Take that time and the project will pay off dividends later.

MODERATOR: Wonderful. ありがとう。 And Tim, bring us home.

TIM NASH: Oh, I want to reinforce what Lawrence said. Security is everybody's responsibility. Give people the time and space to actually do their jobs properly and you'll find that you will come out with a much more secure project.

MODERATOR: Thank you. Security is indeed everyone's responsibility. So thank you to our amazing panelists for taking the time today and also to everybody in the audience. Hope you enjoyed this session. Thank you and bye.