enarx2019年はEnarxの年でした2020年はデモなど色々なプランを考えています!私にとって2019年はEnarxプロジェクトがほとんどでした。Hatを買収してます)の業務、Kubernetesのセキュリティやパートナー企業と協業など重要なことは色々ありました。Enarxが2019年のハイライトです。年始に私たちは実現できることがあると確信し、内部のリーダーシップチームに対して、達成可能であることの証明を課されました。Summitでデモを行い、このブログでアナウンスをしました。Summitでフォローアップをしています。2019年のEnarxの開発でとても大切なことだったと考えています。チームEnarxは私だけのものではもちろん、ありません。McCallumと共にプロジェクトの共同創立者の一人であることは非常に誇りです。ここまで達成できたのは多くのチームメンバーのおかげですし、オープンソースプロジェクトとして貢献し使用している皆様のおかげです。貢献者ページにはたくさんのメンバーの名前がありますが、まだ全員の名前が挙がっているわけではありません。Hat内外の何人かの方から頂いたプロジェクトに対するアドバイス、サポートとスポンサリングはとても大切なものです。その皆様の名前を言う許可は得ていないので、ここではお話しせず、丁重に扱う事とします。皆様のサポートとそのお時間を頂けたことに非常に感謝しています。ユースケースとパートナー2019年に成し得た重要なことの一つに、皆さんがどのように「野良状態で」Enarxを使いたいのかをまとめたことと、その比較的詳細な分析を行い、書き上げたことです。その全てが公開されたわけではないですが、(私が任されていることなんですけどもね)これは実際にEnarxを使用したいと考えているパートナーを見つけるのに不可欠です。公表できませんが、皆さんも聞いたことがあるグローバル企業のいくつかから、また将来的に増えるであろうスタートアップ企業からも、とても興味深いユースケースが挙がってきています。このように興味を持っていただくことは、ロジェクトの実用化に不可欠で、Enarxはただエンジニアの情熱から飛び出しただけのプロジェクトではないと言う事なのです。Consortiumの発表でした。HatではEnarxはこの新しいグループにぴったりだと考えており、10月の正式発足でプレミアメンバーになったことを嬉しく思っています。これを書いている2019年12月31日時点では、会員数は21、このコンソーシアムは幅広い業界で懸念と興味を惹きつけるものだと言うことがはっきりしてきました。Enarxの信念と目的が裏付けされていると言うことです。2019年に成し遂げたのはコンソーシアムへの参加だけではありません。カンファレンスで講演を行い、このブログ上やNext.redhat.comまたOpensource.comで記事を発表、プレスとの会見、ウェブキャストなどです。大切なのは六角形のステッカーを作ったことでしょう!(欲しい方がいらっしゃったらご連絡ください)最後に大切なことを一つ。私たちはプロジェクトを公表していきます。Hat外の参加を促進するために活動しています。詳細は12月17日のBlogをご覧ください。アーキテクチャとコード他に何かあるでしょうか。いくつかのコンポーネントの成熟しつつあるアーキテクチャセットです。私たちは当然これら全てを外部に公表するつもりですが、まだできていない状態です。すべきことが本当にたくさんあるのです。私たちは皆さんが使用できるようにコードを公開することに尽力していて、2020年に向けデモやそれ以外の大きな計画を立てています。最後に他にも大切なことはもちろんあり、私がWileyから出版するトラスト(信頼性)に関連する本を書いていることです。これはEnarxに深く関連するものです。基本的に、技術はとても「クール」なものですが、Enarxプロジェクトは既存の需要に見合うものですから、Nathanielと私はクラウドやIoT、エッジ、その他機密情報とアルゴリズムが実装される全てのワークロードの管理方法を変えていくいい機会だと考えています。このブログはセキュリティに関するものですが、トラスト(信頼性)と言うものはとても重要な部分だと考えています。Enarxはそれにぴったりと合うのです。これからも信頼性とEnarxに関するポストをしていきます。Enarx.ioの最新情報に注目していてください。ー新しいHTTPSとは?デフォルトで付いてくるセキュリティなんてありません。ここ数年、「http://...&#8221」のようなウェブサイトはなくなってきました。これはやっと業界がウェブサイトにセキュリティが「ある」ことに気付いたからです。同時にサーバーとクライアントどちらともHTTPS通信の設定をすることが容易になったからです。同じような動きがクラウド、エッジ、IoT、ブロックチェーン、AI/MLなどのコンピューティングにも現れることでしょう。ストレージ内に保存するデータやネットワークで転送されるデータはは暗号化すべきである、とは認識されていました。プロセスしている間使用されているデータを暗号化するのは難しく、高価でした。(TEE)などのハードウェアを使って、使用中のデータやアルゴリズムを保護します。コンフィデンシャルコンピューティングは、ホストシステムや攻撃されやすい環境のデータを保護するのです。)に付いては何度かブログに投稿しています。EnarxはTEEを使っていて、Enarkでプラットフォームや使用言語に依存せず、機密性が必要なアプリケーションやマイクロサービスなどのコンポーネントを安全に信頼できないホストにデプロイすることができます。Enarxはもちろん完全にオープンソースで(Apache2.0のライセンス使用)です。ワークロードを信頼できないホストで稼働させるのはコンフィデンシャルコンピューティングが保証するところです。これからは下記のような場合の機密性があるデータにコンフィデンシャルコンピューティングが普通に使われるようになるでしょう。:ストレージ:ストレージインフラを完全に信用できないので、保存したデータは暗号化したいネットワーク:ネットワークインフラを完全に信用できないので、転送中のデータを暗号化したいコンピューティング:コンピューティングインフラを信用できないので、使用中のデータを暗号化したい信頼信用に関してはもっと言いたいことはあるのですが「完全に」という言葉が大切です。(これは推敲の最中に書き足しました。)パケットを送ったりやブロックを保存したりするかどうか、上記のどのケースでもCPUやファームウェアなど、インフラをある程度信頼しなくてはいけません。いうのも、それらを信頼できなければコンピューティングなんてできません。(準同型暗号という技術があり提供されつつありますが、まだ限定的で技術も未完成です)CPU周りで見つかる脆弱性があると、CPUを完全に信頼するかどうか、また乗っているホストの物理攻撃に完全に安全がどうか、というのは何度も出てくる疑問です。どちらの疑問にも、「いいえ」と答えられますね。拡張性とデプロイの費用の問題から現状ではベストな技術でしょう。二番目の疑問については、誰も(もしくは他の技術)完全に安全だと偽装できないということです。考慮し、この場合ではTEEが特定の要件に対して十分なセキュリティを提供できるかどうか決定する、ということです。一つ目の疑問に関してはEnarxの当てはまるモデルは、特定のCPUセットを信頼するかどうかデプロイメントの際に全て決め打ちする、ということでしょう。QというベンダのR世代のチップに脆弱性が見つかったとしましょう。「ワークロードをQから出ているR世代のCPUにはデプロイさせず、Q社のSタイプ、Tタイプ、Uタイプのチップと、P社、M社、N社のCPUにはデプロイOKとする」と宣言できれば簡単ですね。コンフィデンシャルコンピューティングが注目されていますが、そこに適応させるには3つの変化のステージがあると考えています。ハードウェアの稼働性:TEEがサポートされているハードウェアが手に入るようになったのはここ半年から一年の間です。IntelのSGXやAMDのSEVなど市場で鍵となる製品が出てきだことからもわかります。これからもTEEが使えるハードウェアの製品が出てくると予想されます。業界の受け入れ状態:アプリケーションのデプロイメントとしてクラウドが急激に受け入れられているのに合わせて法規制や整備は扱うデータを保護するよう、組織や団体に対して要求を増やしてきています。組織や団体は、信頼性のないホストでの機密性の高いアプリケーション(もしくは機密データを扱うアプリ)の稼働方法にざわざわしてきています。正確には、彼らが完全に信用できないホスト上で、のアプリに関してですね。これは別に驚くことではないのです。マーケットが投資に値するものではなければ、チップベンダーはこの技術に投資しないでしょう。(CCC)の体制は、どれくらい業界がコンフィデンシャルコンピューティングの共通使用モデルを見つけようとしているか、オープンソースプロジェクトにこのような技術採用を勧めているか、の別のよい例ですね。Hatが始めたEnarxはCCCのプロジェクトです。オープンソース:ブロックチェーンのように、コンフィデンシャルコンピューティングはオープンソースを使うことがとても簡単な技術の一つです。機密性の高いアプリケーションを動かす場合、動いているもの自体を信用しなくてはいけません。CPUやファームウェアのようなものではなく、TEEの中でワークロードの実際の実行を手伝うフレームワークのことです。良い言い回しがあります。「私はホストマシーンとソフトウェアスタックが信用できないからTEEを使うんだ」しかしTEEのソフトウェア環境に可視性がなければ、ただソフトウェアを別の不可視性の高い環境に移しただけです。TEEのオープンソースによって、あなたやコミュニティ5トはプロプライエタリのベンダー仕様ソフトウェアにはできないチェックと監査ができるようになるのです。Foundationに属しているのであり、TEEに関するソフトウェアプロジェクトにCCCに参加するよう、またオープンソースにするように推進しているのです。このハードウェアの可動性、業界の受け入れとオープンソースの三つがここ15から20年の技術の変革を促進するものだと考えます。ブロックチェーン、AI、クラウドコンピューティング、ウェブスケールコンピューティング、ビッグデータ、インターネット販売は全てこの三つが合わさって、今までになかった変革を業界にもたらしたのです。デフォルトのセキュリティはここ何十年か必要だと訴えられているものですが、まだ達成されていません。正直なところ、それが本当に実現するかはわかりません。新しい技術が実現することで、業界で、特定のユースケースにセキュリティが浸透することがもっと実用的になり、そこに期待も集まるでしょう。コンフィデンシャルコンピューティングは次の新しい変革を迎えようとしています。読者の皆さんがその革命に参加する日が来るでしょう。オープンソースなのですから。ー新しいHTTPSとは?プロジェクトとプロダクトとセキュリティコミュニティと全てのオープンソースが平等に作られてメンテナンスされている訳ではないのです。オープンソースは良いこと、です。オープンソースは特にセキュリティ周りにはピッタリです。Sourceでも書きましたが、さらに書き足したいと思います。この記事ではオープンソースの機能、議論の余地はありますが、その欠点と利点についてついてです。いうと、プロジェクトとプロダクトの違いです。一面から話しますが(あらかじめ警告すると、組織にとっては「プロダクト」なのですが)、ここでちょっとした免責事項から始めましょう。Hatに勤めています。Hatはオープンソースをサポートすることで利益を得ている企業です。これは良いことで、私はこの企業モデルを認めていますが、この記事に関してはバイアスがかかってることをはじめにお伝えします。オープンソースがセキュリティに良いという理由は、問題があるときに何が起こっているか実際自分で見ることができる上、自分で修正することもできるからです。現実的に言うと、問題が起こったオープンソースプロジェクトでセキュリティプロフェッショナルかつその分野のエキスパートでなければ、他の人が修正してくれるかもしれません。その分野に詳しいセキュリティ関連の人が十分にいて、ソフトウェアプロジェクトの中の問題や脆弱性を解決してくれるのを願うばかりです。それよりはもっと事態は複雑かもしれません。組織としてはオープンソースを使用するには二つの方法があります。・プロジェクトとしてコードを持ってきてどのバージョンを使うか決め、自分でコンパイル、テスト、管理をする・プロダクトとしてベンダーがプロジェクトを持ってきて、どのバーションか決め、コンパイル、テスト、サポートをパッケージにつけて売ります。ドキュメントやパッチ、アップデートも大抵含みます。「生」プロジェクトを使えばオプションがもっとあることを否定はできませんね。最新バージョンをチェックして、コンパイル、テストを自由にでき、プロダクトバージョンよりも早く、さらに自分のビジネスとユースケースに合ったセキュリティパッチを当てることもできます。良いことのように思えますしかしながら、セキュリティ特有の欠点があります。セキュリティパッチの中には規制があるものがあります。(ブログ参照)限られた組織(大体はベンダーです)だけがアクセスできるものです。大きなエコシステムと同時期にアクセスを得て修正できたとしても、チェックして、テストをしなければいけません。それもベンダーによってすでにされているかもしれません。必要性も緊急性がないのにコード変更をしたいという大きな欲求をアップストリームプロジェクトに反映させることは、コードをフォークしているようなものです。期日通りにアップストリームに入れこめたとしても、その期間中はアップストリームにない変更を維持していることになるので、他のセキュリティパッチがあなたのバージョンにすぐに当てられないと言う危険性があります。(これはセキュリティ関連ではないパッチにも当てはまりますが、セキュリティパッチの方が緊急性があります)オプションとしてもちろんあなたのバージョンが他の人に使ってもらえるのであれば、プロジェクトのオフィシャルフォークにすることもできます。コミュニティにそこを推すこともできます、しかしその新しいバージョンを内部的または外部的にサポートし続けるか決めなければいけません。ソフトウェアの全てのインスタンスを同じ環境で同じバージョンで稼働させているのでない限り、セキュリティパッチを古いバージョンにバックポートすることが必要です。するのであれば、はじめに修正を行った人と同等もしくは同等程度にセキュリティに精通していなければいけません。この場合、オープンソースの「共同体」と言う利点を捨てるということです。コミュニティのスキルをコピーできるようなエキスパートを雇う必要があるからです。プロダクトではなくプロジェクトをデプロイするということは、プロジェクトを内部でプロダクト化するようなものです。セキュリティパッチの「共同体」の利点だけでなく、ベンダーサポートプロダクトモデルに本来ある「規模の経済」を失うことになります。「範囲の経済」も失っているかもしれません。多くのベンダーはたくさんのプロダクトをサポートしています。エキスパートをあてがうことができるかもしれません。このような経済学で見ると、ベンダーを使うことの「共同体」の利点がわかります。たくさんの顧客が製品を使うということは、セキュリティパッチと主要な機能に収益構造とインセンティブを見出せるということなのです。他のパッチや機能向上にリソースをあてがう場合もあるかもしれません。スキルのあるセキュリティエキスパートが不足しているということは、「比較優位」性が訴えるように、大きなコミュニティの利点のためにそのポジションを保持すべきなのです。ベンダーがオープンソースプロジェクトを製品化したバージョンを終わりにする、もしくはサポートを終了する場合どうなるでしょう。ベンダー固有のソフトが持つ問題です。ベンダーソフトの場合、3つのアウトカムがあります。・ソフトウェアのソースコードにアクセスできないので、機能向上はできない・あなただけがソースコードにアクセス権を与えられているが、広げることができないので孤立している・全ての人がソースコードにアクセスできるが、機能向上させることができるコミュニティがないので、ソフトが消える、もしくはコミュニティがソフト周りを整えるのにものすごい時間がかかるオープンソースの場合、選択したベンダーがビジネスを終了させたら、別のベンダーを使う、新しいベンダーに引き継いでもらう、自分で製品化する(その上で別の組織に提供する)、最悪の場合は内部で製品化して長期的な対策を練る、などのオプションがあります。最近のオープンソースの世界では私たちコミュニティはオープンソースのコンソーシアムの成長とともに、これらのオプションを上手く使えるようになってきました。コンソーシアムではソフトウェアのプロジェクトやそれに関わるプロジェクト周りで組織や団体、個人が集まって上記にあげた規模の経済と範囲の経済を模索しながら、コミュニティの成長促進、機能周りや追加機能を一律にしたり、まだ上手く定義されていないユースケースの一般的なセキュリティ周りや製品化をしたりしています。Consortiumでしょう。オープンソースのソフトをプロジェクトとしてではなくプロダクトとして使うということは、トレードオフがあります。少なくともセキュリティの観点から言うと、組織の経済についてはとても明確です。セキュリティのエキスパートを雇う立場出ないのであれば、プロダクトが一番ニーズにあっているのです。WordPress.com.。