Coming to you in Japanese

We are now multi-lingual.

I have an exciting announcement, which is that starting this week, some of the articles on this blog will also be in Japanese.  My very talented Red Hat colleague Yuki Kubota showed an interest in translating some which she thought might be of interest to Japanese readers, and I jumped at the chance.  I’m very thrilled and humbled.

We’re still ironing out the process, but hopefully (if you already read Japanese), you’ll be able to read the following articles.

We’ll try to add the tag “Japanese” to each of these, as well.

So, a huge thank you to Yuki: we’d love comments – in English or Japanese!

2019年はEnarxの年でした

2020年はデモなど色々なプランを考えています!

 

私にとって2019年はEnarxプロジェクトがほとんどでした。

他のしなければいけない業務もあって、例えば顧客会議、IBM(7月に私の勤めるRed Hatを買収してます)の業務、Kubernetesのセキュリティやパートナー企業と協業など重要なことは色々ありました。しかしEnarxが2019年のハイライトです。

 

年始に私たちは実現できることがあると確信し、内部のリーダーシップチームに対して、達成可能であることの証明を課されました。

その課題に対して、私たちはAMDのSEVチップと五月のボストンでのRed Hat Summitでデモを行い、このブログでアナウンスをしました。

IntelのSGXチップセットと10月のリヨンでのOpen Source Summitでフォローアップをしています。2019年のEnarxの開発でとても大切なことだったと考えています。

 

チーム

 

Enarxは私だけのものではもちろん、ありません。Nathaniel McCallumと共にプロジェクトの共同創立者の一人であることは非常に誇りです。ここまで達成できたのは多くのチームメンバーのおかげですし、オープンソースプロジェクトとして貢献し使用している皆様のおかげです。貢献者ページにはたくさんのメンバーの名前がありますが、まだ全員の名前が挙がっているわけではありません。また、Red Hat内外の何人かの方から頂いたプロジェクトに対するアドバイス、サポートとスポンサリングはとても大切なものです。その皆様の名前を言う許可は得ていないので、ここではお話しせず、丁重に扱う事とします。皆様のサポートとそのお時間を頂けたことに非常に感謝しています。

 

ユースケースとパートナー

 

2019年に成し得た重要なことの一つに、皆さんがどのように「野良状態で」Enarxを使いたいのかをまとめたことと、その比較的詳細な分析を行い、書き上げたことです。

その全てが公開されたわけではないですが、(私が任されていることなんですけどもね)これは実際にEnarxを使用したいと考えているパートナーを見つけるのに不可欠です。まだ公表できませんが、皆さんも聞いたことがあるグローバル企業のいくつかから、また将来的に増えるであろうスタートアップ企業からも、とても興味深いユースケースが挙がってきています。このように興味を持っていただくことは、ロジェクトの実用化に不可欠で、Enarxはただエンジニアの情熱から飛び出しただけのプロジェクトではないと言う事なのです。

 

外部を見ると

 

2019年の重大イベントはLinux FoundationのOpen Source SummitでのConfidential Computing Consortiumの発表でした。私たちRed HatではEnarxはこの新しいグループにぴったりだと考えており、10月の正式発足でプレミアメンバーになったことを嬉しく思っています。これを書いている2019年12月31日時点では、会員数は21、このコンソーシアムは幅広い業界で懸念と興味を惹きつけるものだと言うことがはっきりしてきました。Enarxの信念と目的が裏付けされていると言うことです。

 

2019年に成し遂げたのはコンソーシアムへの参加だけではありません。カンファレンスで講演を行い、このブログ上やNext.redhat.comまたOpensource.comで記事を発表、プレスとの会見、ウェブキャストなどです。一番大切なのは六角形のステッカーを作ったことでしょう!(欲しい方がいらっしゃったらご連絡ください)

 

最後に大切なことを一つ。私たちはプロジェクトを公表していきます。内製のプロジェクトからRed Hat外の参加を促進するために活動しています。詳細は12月17日のBlogをご覧ください。

 

アーキテクチャとコード

 

他に何かあるでしょうか。そうだ、コードですね。そしていくつかのコンポーネントの成熟しつつあるアーキテクチャセットです。

私たちは当然これら全てを外部に公表するつもりですが、まだできていない状態です。すべきことが本当にたくさんあるのです。私たちは皆さんが使用できるようにコードを公開することに尽力していて、2020年に向けデモやそれ以外の大きな計画を立てています。

 

最後に

 

他にも大切なことはもちろんあり、私がWileyから出版するトラスト(信頼性)に関連する本を書いていることです。これはEnarxに深く関連するものです。基本的に、技術はとても「クール」なものですが、Enarxプロジェクトは既存の需要に見合うものですから、Nathanielと私はクラウドやIoT、エッジ、その他機密情報とアルゴリズムが実装される全てのワークロードの管理方法を変えていくいい機会だと考えています。

 

このブログはセキュリティに関するものですが、トラスト(信頼性)と言うものはとても重要な部分だと考えています。Enarxはそれにぴったりと合うのです。ですから、これからも信頼性とEnarxに関するポストをしていきます。Enarx.ioの最新情報に注目していてください。

 

元の記事:https://aliceevebob.com/2019/12/31/2019-a-year-of-enarx/

2019年12月31日 Mike Bursell

 

タグ:セキュリティ、Enarx、オープンソース、クラウド

 

オープンソースプロジェクトを始める7つのアドバイス

プロジェクト手法ではなく…

私は今Enarxプロジェクトに関わっています。とても深く、です。すでにご存知かもしれませんが、これはオープンソースのプロジェクトで、信頼できないホスト上で機密性の高いワークロードの実行を可能にするプロジェクトです。

 

何年もオープンソースプロジェクトに関わってきましたが、このプロジェクトで初めて私は共同創立者となりました。

私たちは現状、コードや文書を十分用意し、ロゴもステッカーも(これ重要!)用意できている段階です。

 

プロジェクトはLinux Foundationグループ(Confidential Computing Consortium)に含まれるはずなので、順調です。さらにプロジェクトを加速させるためにも内容に関してもお伝えしていったほうがいいでしょう。はっきりさせておくと、Enarxは商用とエンタープライズアプリケーションになるプロジェクトです。十分には成熟しておらず、まだまだハードルやチャレンジがあるかもしれません。さらに言うと、私たちの歩んできた道は全てのプロジェクトも当てはまらないかもしれませんが、他のプロジェクトやこれからプロジェクトを始めようとする人への指針になればと思っています。

 

ここまで来るにはたくさんのサポートがあったことをまずお伝えします。

私はOpenSource.comから始めましたが、ここではたくさんのガイドが載っています。それに従っても間違ってしまうこともあるかもしれません。ただ、以下に考慮すべき点を挙げておきます。

 

1 クリティカルマスを目標に

 

私は幸いにもRed Hatと言う素晴らしい職場で働いています。ここでは全てのものがオープンソースですし、オープンソースとそのコミュニティを非常に重要だと考えています。そこで「クリティカルマス」企業と言うものを耳にしました。物事を実際に行っていくには十分な人々の関心が必要で、人々が無視できないものとする必要があるということです。共同創立者のNathaniel McCallumと私はプロジェクトに情熱的で、組織内でスポンサーを得ることに時間をかけました。(誰のことだかわかりますよね、皆さんに感謝です!)そしてエンジニア達に「売り込み」をして惹き込み、プロジェクトが止まれなくなるくらいほどにしました。

プロジェクトのいくつかは一人二人の貢献者しか得ることができずもたついてしまいますが、人々の興味を惹きつけるには、どんどん進めてくれる、ある程度の人数を集めることが必須なのです。

 

2 デモ

 

人々を巻き込みたければデモをすると良いでしょう。洗練されている必要はなく、しようとしていることが実現可能であること、あなたが成し得たいことを示さなければいけません。初期段階のデモではコマンドラインの出力だけでしょうが、UIプロダクトを提供するのでなければ、それでもいいんです。成し遂げようとすることと情熱、プロジェクトの大切さを伝えることが有益なのです。人は何かを「見たい」「体験したい」ので、形にしてやる気を見せることが近道なのです。

 

3 ライセンスを選ぶ

コードをオープンソースで作ると、他の人にも貢献してもらいたくなるでしょう。これはあまり重要ではなく、正しいオープンソースのライセンスを選択することが他の人の貢献度を高め、定義された用語の理解を深め、その貢献する人働いている組織とその人たち自身の貢献するハードルを下げるのです。

 

4 文書作成

 

開発者文書が最重要だと考えるかもしれません。それなければどうやって人が貢献してコードを書くことができるでしょうか。

 

初めのうちは必要ないと思っています。小さなプロジェクトではコードが何をするものか、何をさせたいか、何が欠けているかいるか、の説明をすることで何人かの人を巻き込むことができます。

しかしコードが何をするものでどう便利か説明する文書がないのに、どうやってたくさんの人が時間を割いてくれるでしょうか。

 

文書といっても、ちゃんとしたマーケティング用のものだったり正式なものである必要はなくて、どうしてそれをしなくてはいけないかと皆さんに伝えるものでなければいけません。

これは一番目のポイント、クリティカルマスに注力することにも通じています。文書、ユースケースを示すことで、「ポイント」でプロジェクトが実現したいことに説得力を持たせるのに役立ちます。

 

私たちはgithubウィキをメインの文書置き場にしていて、作成と同時にアップデートしています。これはもう少し改善できるかと思います。

 

5 見えるプロジェクト

 

プロジェクトがちゃんと見える状態でないと見つけてもらえません。私たちのプロジェクトはとてもラッキーで、Confidential Computing Consortiumができた上にそこで見せられるだけのプラットフォームをすぐに作ることができたので、クリティカルマスに届く状態です。

 

Twitterのアカウントもあり(@enarxproject)このブログOpensource.comで記事も出しています。Red Hatのhttps://next.redhat.com/にてブログを出す機会にも恵まれ、プレスのインタビューも受けましたし出来るだけカンファレンスでも講演しています。私たちにはこのような良い機会がありましたが、全てのプロジェクトに適切なアプローチではないかもしれません。しかし知ってもらうことで、もっとたくさんの人々に貢献してもらえます。

 

6 歓迎しましょう

世間に知って頂けたとしましょう。次は何ができるでしょうか。そう、皆さんにプロジェクトに参加したいと思って頂きたいですよね。歓迎してもらえなければその参加数は少なくなって行きます。また上の方で私が何を言ったかに関わらず、しばらくすると技術文書も必要になります。そしてその人たちがあなたと話し合う方法が必要ですね。そうすることで評価されていると感じますから。

 

私たちの場合、Gitter(https://gitter.im/enarx/)で、毎日のスタンドアップ会議には参加したい人がみんな参加できます。最近ではそ課題データベース(https://github.com/enarx/enarx/issues)をGithubに作成しタコとで、スレッドの会話でタイムゾーンがあることから毎日のスタンドアップ会議の時間が合っていないことが明らかになりました。ので、会議の数を少なくとも週一とする配慮をしたのです。

 

7 仲の良い人と活動しましょう

 

私はとてもとてもEnarxプロジェクトチームのみんなと働くことが楽しいです。楽しく過ごし、冗談をかわし、笑って、共通の目標をシェアしています。Enarxの成功のためです。出来るだけ楽しんですること、それが大切だと思います。特にプロジェクトの初期段階では情熱的な人と楽しく仕事できる人が必要です。例えその人が地理的には数千キロ(マイル?)離れた場所にいても、です。そのように参加できなければ情熱もどんどん先細ってくるでしょうし勢いも失われ、プロジェクトは失敗に終わるでしょう。一緒に活動する人は選べるわけではないでしょうが、できればあなたの仲が良い人を選びましょう。

 

結論:「人」です。

 

この記事を書き始めるまでは気づきませんでしたが、全くプロジェクト手法が問題ではないのです。

 

人、です。

 

読み返せばどのアドバイスにも人の大切さが述べてあり、ライセンスの選び方にも、です。オープンソースプロジェクトとはコードではないのです。人なのです。どのようにシェアし、一緒に活動し交流するかなのです。

 

オープンソースプロジェクトはそれぞれ異なるものでしょうから、この7つのアドバイスが全て当てはまることはないでしょう。間違いなくEnarxはまだ成功と言い切れるものではありませんので、今の段階でこのようなアドバイスをすべきでないのかもしれません。しかし成功してきた今までのオープンソースプロジェクトを思い起こすと、やはり人と言うものはとても大切なのです。

 

元の記事:https://aliceevebob.com/2019/12/17/7-tips-for-kicking-off-an-open-source-project/

2019年12月7日 Mike Bursell

 

タグ:オープンソース

 

コンフィデンシャルコンピューティング ー新しいHTTPSとは?

デフォルトで付いてくるセキュリティなんてありません。

この記事は
https://aliceevebob.com/2019/12/03/confidential-computing-the-new-https/ を翻訳したものです。
ここ数年、「http://…&#8221」のようなウェブサイトはなくなってきました。これはやっと業界がウェブサイトにセキュリティが「ある」ことに気付いたからです。と同時にサーバーとクライアントどちらともHTTPS通信の設定をすることが容易になったからです。

同じような動きがクラウド、エッジ、IoT、ブロックチェーン、AI/MLなどのコンピューティングにも現れることでしょう。

ストレージ内に保存するデータやネットワークで転送されるデータはは暗号化すべきである、とは認識されていました。けれどプロセスしている間使用されているデータを暗号化するのは難しく、高価でした。

Trusted Execution Environment (TEE)などのハードウェアを使って、使用中のデータやアルゴリズムを保護します。コンフィデンシャルコンピューティングは、ホストシステムや攻撃されやすい環境のデータを保護するのです。

TEE とEnarx Project(Nathaniel McCallumと共同創立しているプロジェクトです、参考: Enarx for everyone (a quest) and Enarx goes multi-platform )に付いては何度かブログに投稿しています。
EnarxはTEEを使っていて、Enarkでプラットフォームや使用言語に依存せず、機密性が必要なアプリケーションやマイクロサービスなどのコンポーネントを安全に信頼できないホストにデプロイすることができます。

Enarxはもちろん完全にオープンソースで(Apache2.0のライセンス使用)です。
ワークロードを信頼できないホストで稼働させるのはコンフィデンシャルコンピューティングが保証するところです。これからは下記のような場合の機密性があるデータにコンフィデンシャルコンピューティングが普通に使われるようになるでしょう。:

ストレージ:ストレージインフラを完全に信用できないので、保存したデータは暗号化したい
ネットワーク:ネットワークインフラを完全に信用できないので、転送中のデータを暗号化したい
コンピューティング:コンピューティングインフラを信用できないので、使用中のデータを暗号化したい

信頼信用に関してはもっと言いたいことはあるのですが「完全に」という言葉が大切です。(これは推敲の最中に書き足しました。)
パケットを送ったりやブロックを保存したりするかどうか、上記のどのケースでもCPUやファームウェアなど、インフラをある程度信頼しなくてはいけません。というのも、それらを信頼できなければコンピューティングなんてできません。
(準同型暗号という技術があり提供されつつありますが、まだ限定的で技術も未完成です)

CPU周りで見つかる脆弱性があると、CPUを完全に信頼するかどうか、また乗っているホストの物理攻撃に完全に安全がどうか、というのは何度も出てくる疑問です。
どちらの疑問にも、「いいえ」と答えられますね。しかし拡張性とデプロイの費用の問題から現状ではベストな技術でしょう。

二番目の疑問については、誰も(もしくは他の技術)完全に安全だと偽装できないということです。私たちがすべきなのはthreat model を考慮し、この場合ではTEEが特定の要件に対して十分なセキュリティを提供できるかどうか決定する、ということです。

一つ目の疑問に関してはEnarxの当てはまるモデルは、特定のCPUセットを信頼するかどうかデプロイメントの際に全て決め打ちする、ということでしょう。
例えばQというベンダのR世代のチップに脆弱性が見つかったとしましょう。「ワークロードをQから出ているR世代のCPUにはデプロイさせず、Q社のSタイプ、Tタイプ、Uタイプのチップと、P社、M社、N社のCPUにはデプロイOKとする」と宣言できれば簡単ですね。

コンフィデンシャルコンピューティングが注目されていますが、そこに適応させるには3つの変化のステージがあると考えています。

1 ハードウェアの稼働性:
TEEがサポートされているハードウェアが手に入るようになったのはここ半年から一年の間です。IntelのSGXやAMDのSEVなど市場で鍵となる製品が出てきだことからもわかります。
これからもTEEが使えるハードウェアの製品が出てくると予想されます。

2 業界の受け入れ状態:
アプリケーションのデプロイメントとしてクラウドが急激に受け入れられているのに合わせて法規制や整備は扱うデータを保護するよう、組織や団体に対して要求を増やしてきています。
組織や団体は、信頼性のないホストでの機密性の高いアプリケーション(もしくは機密データを扱うアプリ)の稼働方法にざわざわしてきています。正確には、彼らが完全に信用できないホスト上で、のアプリに関してですね。

これは別に驚くことではないのです。もしマーケットが投資に値するものではなければ、チップベンダーはこの技術に投資しないでしょう。
Linux FoundationのConfidential Computing Consortium (CCC)の体制は、どれくらい業界がコンフィデンシャルコンピューティングの共通使用モデルを見つけようとしているか、オープンソースプロジェクトにこのような技術採用を勧めているか、の別のよい例ですね。

その一つがRed Hatが始めたEnarxはCCCのプロジェクトです。

3 オープンソース:
ブロックチェーンのように、コンフィデンシャルコンピューティングはオープンソースを使うことがとても簡単な技術の一つです。

機密性の高いアプリケーションを動かす場合、動いているもの自体を信用しなくてはいけません。CPUやファームウェアのようなものではなく、TEEの中でワークロードの実際の実行を手伝うフレームワークのことです。

良い言い回しがあります。
「私はホストマシーンとソフトウェアスタックが信用できないからTEEを使うんだ」

しかしTEEのソフトウェア環境に可視性がなければ、ただソフトウェアを別の不可視性の高い環境に移しただけです。
TEEのオープンソースによって、あなたやコミュニティ5トはプロプライエタリのベンダー仕様ソフトウェアにはできないチェックと監査ができるようになるのです。

このようにCCCはオープンな開発モデルをであるLinux Foundationに属しているのであり、TEEに関するソフトウェアプロジェクトにCCCに参加するよう、またオープンソースにするように推進しているのです。

このハードウェアの可動性、業界の受け入れとオープンソースの三つがここ15から20年の技術の変革を促進するものだと考えます。
ブロックチェーン、AI、クラウドコンピューティング、ウェブスケールコンピューティング、ビッグデータ、インターネット販売は全てこの三つが合わさって、今までになかった変革を業界にもたらしたのです。

デフォルトのセキュリティはここ何十年か必要だと訴えられているものですが、まだ達成されていません。正直なところ、それが本当に実現するかはわかりません。

しかし新しい技術が実現することで、業界で、特定のユースケースにセキュリティが浸透することがもっと実用的になり、そこに期待も集まるでしょう。

コンフィデンシャルコンピューティングは次の新しい変革を迎えようとしています。
そして読者の皆さんがその革命に参加する日が来るでしょう。オープンソースなのですから。
元の記事:https://aliceevebob.com/2019/12/03/confidential-computing-the-new-https/
2019年12月3日 Mike Bursell

 

プロジェクトとプロダクトとセキュリティコミュニティと

全てのオープンソースが平等に作られてメンテナンスされている訳ではないのです。

この記事は https://aliceevebob.com/2019/10/15/of-projects-products-and-security-community/ を翻訳したものです。
オープンソースは良いこと、です。
オープンソースは特にセキュリティ周りにはピッタリです。

このことに関しては前の記事 Disbelieving the many eyes hypothesisThe commonwealth of Open Sourceでも書きましたが、さらに書き足したいと思います。

この記事ではオープンソースの機能、議論の余地はありますが、その欠点と利点についてついてです。さらにいうと、プロジェクトとプロダクトの違いです。

一面から話しますが(あらかじめ警告すると、組織にとっては「プロダクト」なのですが)、ここでちょっとした免責事項から始めましょう。

私はRed Hatに勤めています。そして、Red Hatはオープンソースをサポートすることで利益を得ている企業です。
これは良いことで、私はこの企業モデルを認めていますが、この記事に関してはバイアスがかかってることをはじめにお伝えします。

オープンソースがセキュリティに良いという理由は、問題があるときに何が起こっているか実際自分で見ることができる上、自分で修正することもできるからです。
もしくは現実的に言うと、問題が起こったオープンソースプロジェクトでセキュリティプロフェッショナルかつその分野のエキスパートでなければ、他の人が修正してくれるかもしれません。
その分野に詳しいセキュリティ関連の人が十分にいて、ソフトウェアプロジェクトの中の問題や脆弱性を解決してくれるのを願うばかりです。

ただ、それよりはもっと事態は複雑かもしれません。
組織としてはオープンソースを使用するには二つの方法があります。

・プロジェクトとして
コードを持ってきてどのバージョンを使うか決め、自分でコンパイル、テスト、管理をする

・プロダクトとして
ベンダーがプロジェクトを持ってきて、どのバーションか決め、コンパイル、テスト、サポートをパッケージにつけて売ります。ドキュメントやパッチ、アップデートも大抵含みます。

さて、「生」プロジェクトを使えばオプションがもっとあることを否定はできませんね。
最新バージョンをチェックして、コンパイル、テストを自由にでき、プロダクトバージョンよりも早く、さらに自分のビジネスとユースケースに合ったセキュリティパッチを当てることもできます。とても良いことのように思えます

しかしながら、セキュリティ特有の欠点があります。

1 セキュリティパッチの中には規制があるものがあります。(ブログ参照)限られた組織(大体はベンダーです)だけがアクセスできるものです。
大きなエコシステムと同時期にアクセスを得て修正できたとしても、チェックして、テストをしなければいけません。それもベンダーによってすでにされているかもしれません。(もちろん盲目的にパッチを当てることもできますが、しないで!)

2 必要性も緊急性がないのにコード変更をしたいという大きな欲求
をアップストリームプロジェクトに反映させることは、コードをフォークしているようなものです。
期日通りにアップストリームに入れこめたとしても、その期間中はアップストリームにない変更を維持していることになるので、他のセキュリティパッチがあなたのバージョンにすぐに当てられないと言う危険性があります。(これはセキュリティ関連ではないパッチにも当てはまりますが、セキュリティパッチの方が緊急性があります)
オプションとしてもちろんあなたのバージョンが他の人に使ってもらえるのであれば、プロジェクトのオフィシャルフォークにすることもできます。コミュニティにそこを推すこともできます、しかしその新しいバージョンを内部的または外部的にサポートし続けるか決めなければいけません。

3 ソフトウェアの全てのインスタンスを同じ環境で同じバージョンで稼働させているのでない限り、セキュリティパッチを古いバージョンにバックポートすることが必要です。そうするのであれば、はじめに修正を行った人と同等もしくは同等程度にセキュリティに精通していなければいけません。
この場合、オープンソースの「共同体」と言う利点を捨てるということです。つまり、コミュニティのスキルをコピーできるようなエキスパートを雇う必要があるからです。

プロダクトではなくプロジェクトをデプロイするということは、プロジェクトを内部でプロダクト化するようなものです。

セキュリティパッチの「共同体」の利点だけでなく、ベンダーサポートプロダクトモデルに本来ある「規模の経済」を失うことになります。

「範囲の経済」も失っているかもしれません。多くのベンダーはたくさんのプロダクトをサポートしています。それらのプロダクトサポートに重点を置いていない組織にとっては、ハードルが高い方法を使って、セキュリティ のエキスパートをあてがうことができるかもしれません。

このような経済学で見ると、ベンダーを使うことの「共同体」の利点がわかります。
たくさんの顧客が製品を使うということは、セキュリティパッチと主要な機能に収益構造とインセンティブを見出せるということなのです。

他のパッチや機能向上にリソースをあてがう場合もあるかもしれません。しかし、スキルのあるセキュリティエキスパートが不足しているということは、「比較優位」性が訴えるように、大きなコミュニティの利点のためにそのポジションを保持すべきなのです。

もし、ベンダーがオープンソースプロジェクトを製品化したバージョンを終わりにする、もしくはサポートを終了する場合どうなるでしょう。
そう、もちろん、ベンダー固有のソフトが持つ問題です。
ベンダーソフトの場合、3つのアウトカムがあります。

・ソフトウェアのソースコードにアクセスできないので、機能向上はできない
・あなただけがソースコードにアクセス権を与えられているが、広げることができないので孤立している
・全ての人がソースコードにアクセスできるが、機能向上させることができるコミュニティがないので、ソフトが消える、もしくはコミュニティがソフト周りを整えるのにものすごい時間がかかる

オープンソースの場合、選択したベンダーがビジネスを終了させたら、別のベンダーを使う、新しいベンダーに引き継いでもらう、自分で製品化する(その上で別の組織に提供する)、最悪の場合は内部で製品化して長期的な対策を練る、などのオプションがあります。

最近のオープンソースの世界では私たちコミュニティはオープンソースのコンソーシアムの成長とともに、これらのオプションを上手く使えるようになってきました。
コンソーシアムではソフトウェアのプロジェクトやそれに関わるプロジェクト周りで組織や団体、個人が集まって上記にあげた規模の経済と範囲の経済を模索しながら、コミュニティの成長促進、機能周りや追加機能を一律にしたり、まだ上手く定義されていないユースケースの一般的なセキュリティ周りや製品化をしたりしています。

例としては、Enarxプロジェクトも貢献しているLinux FoundationのConfidential Computing Consortiumでしょう。

オープンソースのソフトをプロジェクトとしてではなくプロダクトとして使うということは、トレードオフがあります。

しかし、少なくともセキュリティの観点から言うと、組織の経済についてはとても明確です。セキュリティのエキスパートを雇う立場出ないのであれば、プロダクトが一番ニーズにあっているのです。
元の記事:https://aliceevebob.com/2019/10/15/of-projects-products-and-security-community/
2019年10月15日 Mike Bursell

リモートワークをするときの7つのマイルール

もしオフィスをでなければいけないのであれば、犬の散歩に行きますね!

この記事は
https://aliceevebob.com/2019/08/13/my-7-rules-for-remote-work-sanity/
を翻訳したものです。
この10年から15年の間、ほとんど時間、リモートで仕事をしています。
ラッキーなことに私の仕事はリモートワークがぴったりで、勤めているRed Hatもその環境を整えてくれています。

例えばお客様とオンサイトの会議が多くあったり、主要なサービスコンポーネントに従事しているなど、全ての仕事がリモートワークに合うわけではもちろんないですが、多くの組織がリモートワークを検討しています。

また、なるべく「家から働く」「家で働く」などのフレーズをなるべく避けるようにしています。
後者のフレーズの方が良さそうだ、と聞いたこともありますが、多くのリモートワーカーにとっては正確な言い方ではないでしょう。

実際、私の職種にぴったり合う言い方でもありません。
私の仕事はリモートで、会社によって机や椅子、会議室やインターネットアクセスが準備された仕事場はないのですが、いつも家で過ごしているわけではありません。

一ヶ月に平均して3日から1週間ほどは出張です。カンファレンスで講演したり、実際会っての打ち合わせだったりがあるのです。
この間、大体は連絡のつく状態であり、メールをチェックできることになっています。緊急の連絡やメールにも関わらず出張の機会は増えたり減ったり、です。

オープンソース

私がリモートで働ける理由の一つに、勤めているのがオープンソースソフトの会社であることもあります。
今、Enarxというとてもクールなプロジェクトに従事しています。そのソフトに貢献している仲間は欧米にいて、それ以外にも世界中から問い合わせがきます。

スタンドアップ会議はバーチャルでビデオを使います。
プロジェクトからは少なくとも二人は参加し、私は大体はデスクの横で実際立って参加します。

コードは全てgithub(もちろんオープンソースです!訳注:ブログの発信当時は、です。今はマイクロソフトに買収されています)を使っていて、頻繁に顔を合わせる必要も特にありません。
例えば特別な機会にはどこにいてもケーキを買って一緒に祝い、ステッカーをラップトップにつけて、ブランドとチーム感を大切にしています。
チャットとIRCのチャネルがあって色々な方法でコミュニケーションをしています。
まだ小さなチームですが今の所うまくいっています。
リモートチームとどのように働くかのアドバイスはOpensource.comにたくさん載っています。

環境

出張していないときは基本、自宅にいます。天気にもよりますが通勤もします。30〜45秒の短い通勤です。
私のオフィスは家とは別れていて庭にあり、オフィスチェアやデスク、ラップトップのドッキング、モニター、ウェブカメラ、電話、キーボードとプリンターがあり、部屋の中ははっきりと仕事関連のものだけです。

仕事をする環境を作るのに、大切なものもあります。人によって違うでしょうが、私の場合はこんな感じです。

・ソノス。アンプと良いスピーカーに接続したホームサウンドシステム。
・ソファ。大体、飼っている犬に占領されています。時々猫。
・本棚。本が床に散らばらないように。
・紅茶を淹れるファシリティー。私はイギリス人なので、これは最重要。
・冷蔵庫。紅茶に入れるための牛乳、ビールとワインが入っています。(ご心配なく。就業時間中に飲酒はしません。メインキッチンの冷蔵庫に入らなかったんです)
・大きく開く窓と夏に必要なブラインド(エアコンはありません。先ほど言ったでしょう?私はイギリス人なので)
・床暖房と暖炉。冬に必要です。(床暖房は暖炉が暖まるまで必要なのです)
・NUCのパソコンとモニター。仕事にあまり関係ない作業をするため
・蜘蛛も少々

何が必要かはワークスタイルにもよりますが、仕事に関係ないものが実は大切です。まあ、蜘蛛は要らないかもしれませんが。
これは仕事場を心地よくするためなのです。
例えば集中するために音楽をよく聞きます。飼っている犬や猫とソファーに座って、大量のドキュメントを読みます。
お茶を淹れる場所と冷蔵庫がなければ、米国人になっちゃいます!

マイルール

どうやったらうまくいくでしょう。

まずは私たちのほとんどは、他の人と連絡をすることが好きですよね。

リモートワーカーの中にはシェアワークスペースを借りてそこで働く人もいるでしょう。そういう人はオフィスの環境が好きだったり、仕事に集中できる場所が自宅にないのかも知れません。

他にもコーヒーショップやボート(羨ましい!)で働く人もいるでしょう。一年の半分をオフィスで過ごし、残りを別荘で働く人もいるでしょう。

どのようにするにしろ、あなたにとって最適な場所を探すのが大切です。
以下は私がよくやること、その理由です。

1 なるべく仕事をする時間を決めましょう。
公式的には(同僚の皆さんへFYI、イントラに載っています)イギリス時間午前10時から午後6時まで働いています。
これは、多くの米国の同僚の働いている時間に重なっていて、朝はジョギングやサイクリングをしたり、犬と散歩しています。(下記参照)
最近はあまり時間はないですが、時間を柔軟的に前後させて、大体決まった時間を働くようにしています。

2 ちゃんと起床して紅茶を一杯頂く
オフィス環境にいると大体、他の人の会話やお茶のお誘い、会議室でのミーティングやランチに出かける、などでいい意味で邪魔が入ります。
このようなことは自宅ではありません。なので、ちゃんと体を動かしてデスクに3〜4時間座りっぱなしにならないようにしています。
座りっぱなしは健康によくないですし、作業が非効率になります。
もちろんお茶をもっと楽しめるようにするのも大切です。

3 体を動かさないでいると、通知してくれるアプリ
新しいものですがとても気に入ってます。
一時間体を動かさないと、時計(携帯やPCでもあるでしょうけど)がエクセサイズをするように、と教えてくれます。
他にも色々勧めてくれるのですが、大体無視して、紅茶をいただきます。(なぜだかは、もうわかるでしょう?)

4 デスクの上下稼働機能を有効活用
立ったり座ったりしながら、体勢を変えるようにしています。
姿勢にもいいですし、もっと体に気をつけるようになります。

5 犬の散歩
外に出て少し考え事をしたい時や少しメールの長いディスカッションから離れたい時には、犬の散歩に出かけます。
ずっと仕事のことを考えていないとしても、散歩に行くのは効率的な仕事にとても有効ですし、長目の散歩になってしまってもその日は少し多めに働いて調整します。

6 家族とのルール
私の家族は、私がオフィスにいるときは働いていると知っています。
電話で連絡することも、それが無視される可能性があることも、もしかしたら窓から今時間があるか覗きこむこともあります。でももし対応できなかったら、しません。
例えば紅茶用の牛乳がない!などの緊急事態には相談次第で調整するので、ケースバイケースですね。

7 カフェで紅茶を頂く、大抵はケーキも。
時々違った環境に行ったり、実際に人と話をしたいこともあります。
そんな場合には車に飛び乗って10分、カフェに行きます。
美味しいケーキと紅茶を出すお店を知っているんです。

上に挙げたものは全ての習慣ではないかもしれませんが、私の日常を保つのに大切な事です。

皆さんのルールは違ったものかもしれませんが、ルールを作り、同僚や友達、家族にそのルールがあることを知ってもらうことはとても大切です。

リモートワークは簡単なことではなく、規則化しなければいけないことがあります。でもそんな規則によって、8時間座りっぱなしを防いで、ゆとりが生まれるのです。
元の記事:https://aliceevebob.com/2019/08/13/my-7-rules-for-remote-work-sanity/
2019年8月13日 Mike Bursell

オープンソースと悪人と

この記事は
https://aliceevebob.com/2019/07/30/open-source-and-well-bad-people/
を翻訳したものです。
オープンソースのコードを書いている人にとって、オープンソースソフトというものは誠実なものに見えます。
コードを書いて、皆さんのような善人な方がコードを書き足し、テストをし、文書を作成し、ソフトを使うのです。
オープンソースとは、世界をどんなに良くしてくれていることか!

「悪の帝国と呼ばれる組織や会社」ですら、オープンソースを受け入れ、幸福と愛情あふれる場所になり、コミュニティを支援し、オープンソースは良いものとして採用し布教しているのです。

多くのオープンソースライセンスは、1組織がコードを書き換え、その書き換えたコードをリリースすることなく利益を得ることほぼ不可能なようにできています。
オープンソースの魂はライセンスで、実際に世界を良くしているのです。

この大部分には賛成します。

が、世間で鵜呑みにされたような憶測(それが何であれ)が広まっているのを見ると、不思議に思います。
というのも、オープンソースを使っている全ての人が善人ではないというのは皆さんご存知でしょう。

クラッカー(悪事を行うハッカー)はオープンソースを使います。
薬物の販売人もオープンソースを使っています。
人身売買者もオープンソースを使います。
テロリストだって使っているでしょう。
彼らももしかしたらパッチやテスト、文書作成に貢献しているかもしれません。実際はほとんどないと思いますが。でも一般的に彼らは善人ではないのです。

中には「まあ、中には少しはそういう人もいるかもしれないけど、耐えられる範囲だろう」と肩をすくめてしまうような人もいるでしょう。オープンソースで悪事を働く人に比べたらもっと多くの人がオープンソースによって助かっているでしょうから、引き続き喜んで貢献するでしょうね。
あるいは、オープンソースに貢献するのではなく、どうせ人のためにならないのだから、悪人度合いが低い方を受け入れてしまう、というところでしょうか。

これは実際に有効なことで、 ジョン・スチュアート・ミルの言う功利主義として知られています。(私は哲学者ではないので、非常にざっくりと話していることを了承ください)これはこう説明されることもあります。

「行動は、人類の幸福全体を促進するのにちょうど良く釣り合う」

私もオープンソースが「人類の幸福全体を促進」すればいいと願っています。問題は犯罪者だけが皆さんのオープンソースコードを使うわけではないことです。

実際に「日陰なコト」を行うビジネスもありますし、政府が批判する人間を抑圧することも、警察が市民を監視することもあるでしょう。
これも皆さんコードなのであり、悪事にも使われるのです。

悪事とはなんでしょう。
これは功利主義の哲学に対する反論でよく出ますね。何が良いことで何が悪いことなのかと定義するのは難しいのです。
法を遵守している我々一般の人は、人身売買をするのは悪いことだ、と思います。しかし、中にはグレーゾーンなものもあるのです。

例えばタバコ製造、石油化学の会社、プラスチックの製造業、LGBTQ+の人々を支持しない組織、銃の製造業などです。
意図的に範囲を大きくしています。また、最後の例はあえて選んでいます。

オープンソースの活動を初期に行なっていたのはESRで知られるエリック・レイモンドです。彼は銃を持つ権利をずっと支持しています。彼は公にされている批判をハッカーコミュニティに取り入れ、小銃保持の権利を声に出して支持しています。ESRにとってはこれが「自由」なのです。

彼を批判するつもりはないですが、これは賛成できません。
ただこれで彼が良いと考えているものは私が考えているものと違うことは明確でしょう。
LGBTQ+に関してはとてもリベラルに受け入れていますが、オープンソースのコミュニティにいる人がみんな同じ考えを持っているわけではないでしょう。
オープンソースコミュニティをリベラルだと述べていますが一般論として受け入れられていません。

ハッカーのための辞書として公表されているのですが、平均的なハッカーとは

ふんわりと穏健リベラル。従来の右派左派の政治全体を拒絶するリベラリストの代表を除く。
保守的に一般化して言うとハッカーはどちらかと言うと反独裁主義者。
つまり従来の保守主義と「極」左派は非常に珍しい。ハッカーは非ハッカーよりも大体
a)攻撃的な非政治主義で
b)特異的もしくは特異な政治アイデアを抱き実際日々そう生きようとしている

ジャーゴン・ファイル
少し古いかもしれませんが、この説明は多くのオープンソースコミュニティ内で、コミュニティの一部として意識している人たちが共感するものです。

ただオープンソースのコードの「良い使い方」は「良い組織」が決める、と言うのは、コミュニティとして明らかに賛成できかねます。
もしできたとしても、悪人とされる人々を止められるようなライセンスを作るのは非常に可能性が低いでしょう。
元の記事:
https://aliceevebob.com/2019/07/30/open-source-and-well-bad-people/
2019年7月30日 Mike Bursell

HSMって何?

セキュリティ強化には重要なHSM。ただ、どのプロジェクトにも当てはまるわけじゃありません。

今週も3文字略語です。(訳注:毎週分まだ訳せてません、頑張ります)

HSM(Hardware Security Module)のお話です。

HSMって何だ?何に使うんだっけ?どうして検討する必要があるの?

その話をする前に、「鍵」特に、暗号鍵について考えてみましょう。

 

最近のほとんどの暗号は、実装されているアルゴリズムは特定の簡単なもの(ブロック暗号)で公開されていますし、一般的にも受け入れられています。

アルゴリズムを知っているかとかどのように動いているかは問題ではないんです。というのは問題になるのは鍵の安全性だからです。

 

例として、AESアルゴリズムでデータを暗号化したいとします。これで特定のタイプの(対称)暗号化ができます。(この例では1つのAESタイプだけ使うこととします。実際はいくつも微妙な違いがあってここでは省きますが、ポイントは変わりません)

 

このアルゴリズムには二つのデータを与えられます:

 

  1. 暗号化したい、平文のデータ
  2. 暗号化するための鍵

 

結果としてでたデータは一つです。

 

  1. 暗号化されたデータ

 

この暗号化されたデータを復号するには、AESアルゴリズムに鍵を入れ込見ます。すると元の平文データが出力されます。

この仕組みは非常によく出来ています。鍵が盗み出さなければ、です。

 

ここでHSMが出てきます。鍵はとても大切です。以下の場合、とても攻撃を受けやすいのです:

 

鍵の作成時:もし、暗号鍵を作成した時にヒントとなるビットを埋め込めたら、そのデータは悪意を持って複合される可能性が高くなります。

 

鍵の使用時:データを暗号化したり複合化している間、鍵はメモリ上にあります。つまり、そのメモリを覗き見ることができれば、データを盗み見ることができます。(下記の「サイドチャネルアタック」参照)

 

鍵の保存時:鍵の保存時にしっかりと保護していない限り、鍵が盗まれる可能性があります。

 

鍵の転送時:鍵を使用する場所と違うところに保存している場合、そこに転送する時に盗みとられる可能性があります。

 

HSMは上記の全ての場合に役立ちます。

これが必要となる理由としては、鍵の作成、使用、保存、転送時に、システムの安全性が不確実な場合があるからです。

 

 もし鍵がメールの暗号化に使われるとして、もしそこに侵入されてしまったらとてもみっともない事態に陥ります。もし、これがあなたが持っている全てのクレジットカードのチップに関するものだったら、もっと大変なことになります。

 

もし、そのコンピュートシステムで十分な権限を持っていれば、その権限者はメモリを見て、鍵を得ることもできます。TEE(Trusted Esxecution Environment

)環境でなければ、の話ですけれどね。

 

もっとタチの悪いことに、メモリを見ることができなくても、暗号鍵(もしくは、暗号化データ、平文データ)に関する情報を引き出して、攻撃を仕掛けることができます。このタイプの攻撃は通常「サイドチャネルアタック」と呼ばれます。

 

これは車のエンジンのシリンダーやバルブと同じようなもので、ボンネットを通してエンジンに耳を澄ますのと同じようなことです。エンジン構造はそのつもりではなかったとしても、エンジン部品からエンジンについての情報を盗み見ることができる、ということです。

HSMはそのような攻撃を防ぐように作られているのです。

 

ではHSMの定義をお話ししましょう。

 

HSMとはハードウェアの一つで、ネットワークやPCIのようなものを介して、システムに付随された暗号化作業を行うことができる保護ストレージを持っています。そしてサイドアタック、物理的にこじ開けようとしたり、コンポーネントに物理ケーブルを差し込んで電気信号を読み取ろうとする、などの色々な攻撃から保護する物理防御機能を持っています。

 

数々のHSMは、色々なタイプの攻撃を耐えられることを証明するため

FIPS140などの標準化の認可を取得しようと検査を受けています。

 

以下にHSMの主な使用方法を挙げます。

 

鍵の作成

鍵の作成は上で述べたように、とても大切な作業です。ただサイドアタックが非常に効果的に行われる部分でもあります。HSMは(比較的)安全な鍵の生成をし、鍵に求められる適度なランダム性があります。

 

鍵の保管

HSMは何者かが侵入しようとした場合に保管されている鍵を破棄するようにできているので、鍵の保管には適しています。

 

暗号化処理

 

鍵をHSMという安全な場所から別のシステムに転送して危険に晒すより、暗号化前の平文をHSMに置いてしまってはどうでしょう(できれば転送する場合には転送用の鍵を使ってです)。そしてHSMにすでにある鍵で暗号化させ、暗号化したデータを送り返せば?(ここでも転送中は転送用の鍵を使います)こうすることで転送中と使用中の攻撃の機会を減らします。これがHSMの鍵の使い方です。

 

通常のコンピューティング処理

 

全てのHSMがこの使い方をサポートするわけではなく(他のほとんどの方法はサポートされますが)、鍵とアルゴリズムたくさん使って機密作業をするのであれば、アプリケーションをHSMで動くように書くことができます。

これは例えばAIやMLのような、前に書いたような古いやり方とは違って、非常に機密性のある場合です。

 

簡単に保証できるものではありませんが、実行環境は往往にして非常に制限があります。「正しい」ことをするのは難しく、間違いを犯すのは簡単です。すると思っていたよりも大変安全性の低いことになります。

 

結論 HSMを使うべき?

 

HSMはPKI(Public Key Infrastructure)プロジェクトなどにはルートオブトラスト(信頼性の基点)としてとてもいいものです。

 

使うのは難しいでしょうが、PKCS#11インターフェース(Public Key Cryptography Standard )を提供しているはずなので、共通化した作業は簡易化されています。機密鍵や暗号化の要件がある場合、HSMをシステムで使うのは賢明な選択ですが、どうやって静的化して使うのはアーキテクチャと設計の段階で必要で、構築の十分前段階でする必要があります。

 

日々のプロビジョニングからプロビジョニングの解除の時まで、HSMの作業は非常に注意して行う必要があることを十分に考慮してください。HSMの使用はとても意味があることですがとても高価で拡張性は多くの場合あまりありません。

 

HSMはとても機密性の高いデータとその作業を行うというユースケースには特に最適ですが、軍用や政府、ファイナンスに使われることが多いのです。

HSMは全てのプロジェクトに合うものではないのですが、機密システムの設計と運用の武装化に大切なものなのです。

 

元の記事:https://aliceevebob.com/2019/06/11/whats-an-hsm/

2019年6月11日 Mike Bursell

 

タグ:セキュリティ

HSMって何?

セキュリティ強化には重要なHSM。ただ、どのプロジェクトにも当てはまるわけじゃありません

この記事は https://aliceevebob.com/2019/06/11/whats-an-hsm/ を翻訳したものです。

 
今週も3文字略語です。(訳注:毎週分まだ訳せてません、頑張ります)
HSM(Hardware Security Module)のお話です。
HSMって何だ?何に使うんだっけ?どうして検討する必要があるの?
その話をする前に、「鍵」特に、暗号鍵について考えてみましょう。

最近のほとんどの暗号は、実装されているアルゴリズムは特定の簡単なもの(ブロック暗号)で公開されていますし、一般的にも受け入れられています。
アルゴリズムを知っているかとかどのように動いているかは問題ではないんです。というのは問題になるのは鍵の安全性だからです。

例として、AESアルゴリズムでデータを暗号化したいとします。これで特定のタイプの(対称)暗号化ができます。(この例では1つのAESタイプだけ使うこととします。実際はいくつも微妙な違いがあってここでは省きますが、ポイントは変わりません)

このアルゴリズムには二つのデータを与えられます:

1. 暗号化したい、平文のデータ
2. 暗号化するための鍵

結果としてでたデータは一つです。

1. 暗号化されたデータ

この暗号化されたデータを復号するには、AESアルゴリズムに鍵を入れ込見ます。すると元の平文データが出力されます。
この仕組みは非常によく出来ています。鍵が盗み出さなければ、です。

ここでHSMが出てきます。鍵はとても大切です。以下の場合、とても攻撃を受けやすいのです:

- 鍵の作成時:もし、暗号鍵を作成した時にヒントとなるビットを埋め込めたら、そのデータは悪意を持って複合される可能性が高くなります。

- 鍵の使用時:データを暗号化したり複合化している間、鍵はメモリ上にあります。つまり、そのメモリを覗き見ることができれば、データを盗み見ることができます。(下記の「サイドチャネルアタック」参照)

- 鍵の保存時:鍵の保存時にしっかりと保護していない限り、鍵が盗まれる可能性があります。

- 鍵の転送時:鍵を使用する場所と違うところに保存している場合、そこに転送する時に盗みとられる可能性があります。

HSMは上記の全ての場合に役立ちます。
これが必要となる理由としては、鍵の作成、使用、保存、転送時に、システムの安全性が不確実な場合があるからです。

 もし鍵がメールの暗号化に使われるとして、もしそこに侵入されてしまったらとてもみっともない事態に陥ります。もし、これがあなたが持っている全てのクレジットカードのチップに関するものだったら、もっと大変なことになります。

もし、そのコンピュートシステムで十分な権限を持っていれば、その権限者はメモリを見て、鍵を得ることもできます。TEE(Trusted Esxecution Environment
)環境でなければ、の話ですけれどね。

もっとタチの悪いことに、メモリを見ることができなくても、暗号鍵(もしくは、暗号化データ、平文データ)に関する情報を引き出して、攻撃を仕掛けることができます。このタイプの攻撃は通常「サイドチャネルアタック」と呼ばれます。

これは車のエンジンのシリンダーやバルブと同じようなもので、ボンネットを通してエンジンに耳を澄ますのと同じようなことです。エンジン構造はそのつもりではなかったとしても、エンジン部品からエンジンについての情報を盗み見ることができる、ということです。
HSMはそのような攻撃を防ぐように作られているのです。

ではHSMの定義をお話ししましょう。

HSMとはハードウェアの一つで、ネットワークやPCIのようなものを介して、システムに付随された暗号化作業を行うことができる保護ストレージを持っています。そしてサイドアタック、物理的にこじ開けようとしたり、コンポーネントに物理ケーブルを差し込んで電気信号を読み取ろうとする、などの色々な攻撃から保護する物理防御機能を持っています。

数々のHSMは、色々なタイプの攻撃を耐えられることを証明するため
FIPS140などの標準化の認可を取得しようと検査を受けています。

以下にHSMの主な使用方法を挙げます。
鍵の作成
鍵の作成は上で述べたように、とても大切な作業です。ただサイドアタックが非常に効果的に行われる部分でもあります。HSMは(比較的)安全な鍵の生成をし、鍵に求められる適度なランダム性があります。

鍵の保管
HSMは何者かが侵入しようとした場合に保管されている鍵を破棄するようにできているので、鍵の保管には適しています。

暗号化処理
鍵をHSMという安全な場所から別のシステムに転送して危険に晒すより、暗号化前の平文をHSMに置いてしまってはどうでしょう(できれば転送する場合には転送用の鍵を使ってです)。そしてHSMにすでにある鍵で暗号化させ、暗号化したデータを送り返せば?(ここでも転送中は転送用の鍵を使います)こうすることで転送中と使用中の攻撃の機会を減らします。これがHSMの鍵の使い方です。

通常のコンピューティング処理
全てのHSMがこの使い方をサポートするわけではなく(他のほとんどの方法はサポートされますが)、鍵とアルゴリズムたくさん使って機密作業をするのであれば、アプリケーションをHSMで動くように書くことができます。
これは例えばAIやMLのような、前に書いたような古いやり方とは違って、非常に機密性のある場合です。

簡単に保証できるものではありませんが、実行環境は往往にして非常に制限があります。「正しい」ことをするのは難しく、間違いを犯すのは簡単です。すると思っていたよりも大変安全性の低いことになります。

結論 HSMを使うべき?

HSMはPKI(Public Key Infrastructure)プロジェクトなどにはルートオブトラスト(信頼性の基点)としてとてもいいものです。

使うのは難しいでしょうが、PKCS#11インターフェース(Public Key Cryptography Standard )を提供しているはずなので、共通化した作業は簡易化されています。機密鍵や暗号化の要件がある場合、HSMをシステムで使うのは賢明な選択ですが、どうやって静的化して使うのはアーキテクチャと設計の段階で必要で、構築の十分前段階でする必要があります。

日々のプロビジョニングからプロビジョニングの解除の時まで、HSMの作業は非常に注意して行う必要があることを十分に考慮してください。HSMの使用はとても意味があることですがとても高価で拡張性は多くの場合あまりありません。

HSMはとても機密性の高いデータとその作業を行うというユースケースには特に最適ですが、軍用や政府、ファイナンスに使われることが多いのです。
HSMは全てのプロジェクトに合うものではないのですが、機密システムの設計と運用の武装化に大切なものなのです。
元の記事:https://aliceevebob.com/2019/06/11/whats-an-hsm/
2019年6月11日 Mike Bursell

 

Enarxのアナウンス

うまくいけば、この記事は2019年のボストンでのRed Hat Summitのデモに合わせて、投稿されるはずです。

同僚のNathaniel McCallumが行うデモはEnarxを早期具体化したものです。Enarxはここ数ヶ月Red Hatで私たち数名が行ってきたプロジェクトで、世界に公表する準備ができました。コードがあり、デモがあり、GitHubのレポジトリがあり、ロゴもあります。他にはプロジェクトとして何が必要でしょうか。

それは、人です。

何が課題なのか

クラウドやオンプレミス上でシステム(ホスト)でソフトウェア(ワークロード)を実行する場合、たくさんのレイヤーがあります。意識することはほとんどありませんが、事実存在するのです。通常のクラウドの仮想アーキテクチャのレイヤーの例を以下にあげます。

異なった色はレイヤーセット違ったレイヤーやレイヤーセットを「所有」している異なったレイヤーを表しています。

classic-cloud-virt-arch

下記は似ていますが、通常のクラウドコンテナアーキテクチャを描いたものです。

上記のように色によって違ったレイヤーやレイヤーセットの「所有者」を表しています。

cloud-container-arch

これらの所有者は違ったタイプのもので、ハードウェアベンダー、CSP(クラウドサービスプロバイダ)、OEMだったり、OSベンダ、ミドルウェアベンダー、アプリケーションベンダーだったりします。ワークロードの所有者です。それぞれホスト上で実行するワークロードにとって、レイヤーは実際異なっています。もし同じだったとしても、レイヤーインスタンスのバージョンは違っているかもしれませんし、BIOSバージョン、ブートローダー

、カーネルバージョンが違うかもしれません。

さて、色々な意味で皆さんはこれらには懸念を持っていないかもしれないですね。CSPがレイヤーやバージョンの違いを自分たちの方法で気にならないようにしてくれているかもしれません。けれどここはセキュリティを語るブログです。セキュリティに携わる人のためのブログです。つまり、このブログを読んでくださっているかたは気にする、と言うことです。

私たちが気にしたければいけないと言う理由は、バージョンやレイヤーの違いだけではなく、色々なエンティティです。と言うのも機密性の高いワークロードをこのようなスタック上で安心して、信頼して実行しなければいけません。

それぞれのレイヤーとその所有者を信頼し、それらが行いたいことを実行するだけでなく傷つかないようにしなければいけません。これは機密性の高いワークロードを実行する際にはとても大きなことです。

Enarxとは?

Enarxはそのようなレイヤー全ての信頼性を担保する際の問題を明確にするのを目的としたプロジェクトです。

ワークロードを実行する人にレイヤーとその所有者を減らして、信頼すべきものを最小限に抑えようとしたいと考えています。

TEE(Trusted Execution Environments https://aliceevebob.com/2019/02/26/oh-how-i-love-my-tee-or-do-i/ 参照)を使って、以下のようなアーキテクチャに似たものを提供する予定です。

reduced-arch

このような世界ではCPUとファームウェア、そしてミドルウェアを信用する必要があります。

このミドルウェアがEnarxの部分です。

でもそのほかのレイヤー部分を全て信頼する必要はないのです。アプリケーションの統一性と信頼性を保証するためにTEEを活用するからです。Enarxプロジェクトは、TEEの証明書を提供することで、信頼できる正しいTEE上で実行していることがわかるようにするものです。コードはオープンソース、監査可能です。それによってアプリケーションの直下にあるレイヤーが信頼できるようになります。

最初のコードは公開されていて、(この時点ではAMDのSEV TEEで動きます)皆さんにお知らせできる程度には動きます。

覚えておいてくださいね、あなたのアプリケーションがセキュリティ要件に合致しているかどうかはあなたの責任です🙂

もっと知りたい場合は?

一番簡単な方法は Enarx github https://github.com/enarx をチェックすることです。

今はコードだけですが、これからどんどん情報を足していきます。

が、今しばらくお待ちください。数人しかこのプロジェクトには今時点ではいないのです。ブログは私たちのToDoリストにあったので、私はそこから始めた次第です。

私たちは、コミュニティの方々にプロジェクトに参加していただきたいと思っています。今はとても低いレイヤーでさらに知識を得ていくために尽力しています。もちろん特定のハードウェアも必要になります。そうそう、早期ブートやKVMの低層のハッカーなあなたの参加が特に必要です。

記事にコメントいただければもちろんお答えします。

 

元の記事:

https://aliceevebob.com/2019/05/07/announcing-enarx/

2019年5月7日 Mike Bursell

タグ:セキュリティ、Enarx、オープンソース、クラウド