orangeitems’s diary

40代ITエンジニアが毎日何か書くブログ

デジタルトランスフォーメーション(DX)の幻想を学ぼう

f:id:orangeitems:20180911003615j:plain

 

経済産業省自身がDXをまとめる

デジタルトランスフォーメーション(DX)という掛け声が今年になってよく叫ばれることが多くなりました。いつものバズワードだと捉え静観している人も多いと思いますが、今回経済産業省自らが、「デジタルトランスフォーメーションレポート~IT システム「2025 年の崖」の克服と DX の本格的な展開~」という文書をリリースするに至りいよいよ、いろんな経営者が感化され技術者レベルで無視できない状況に差し掛かったようです。

 

www.meti.go.jp

経済産業省は、我が国企業がデジタルトランスフォーメーション(DX)を実現していく上でのITシステムに関する現状の課題の整理とその対応策の検討を行い、『DXレポート~ITシステム「2025年の崖」の克服とDXの本格的な展開~』として報告書を取りまとめました。

 

とても長いですが、システムエンジニアあるいはIT業界の営業の方は最後まで読むことをお勧めします。というのは、今後ベンダー側はもちろんのこと、経営者がDXについていろんなセミナーを受け、「わが社もDX!」と言い始めることが間違いないためです。

どんな文脈でDX協奏曲が始められたのか、今のうちに読破しておくことでスムーズに立ち回れるようになれると思います。

 

書評

つらつらと、読んだ感想を書いていきます。

まずはこの文章自体、DXに対する定義が文脈によって揺らいでいきます。もともとの根源的な意味は、自社のこれまでの経済活動をゼロベースで見直しデジタル中心のワークフローにすることで、市場でゲームチェンジャーとなることができ競争を勝ち抜くことができることです。しかし、じゃあ具体的にDXって何をするの?と問われると、AI、IoT、マイクロサービス、クラウド、AR/VR、ビッグデータ、アジャイル型開発・・です、とあります。ここで大きくずれています。おそらくIoTだけマイクロサービスだけ、小さく切り取ってPoC(研究)したとしても、なーんにもならないというのが日本流DX失敗です。まずはゲームチェンジするために最新の技術と現在のビジネスモデルをどうトランスフォーメーションするかを考えることが先です。昨今のDXの盛り下がりは各個別技術ばかりがフォーカスされ、結局DXできるかはやってみて考えるというふうな仕事の進め方に大きな問題を抱えているのでしょう。全体的にもやもやするのは、DX自体はドリームであり、個別技術によってドリームを実現できるかどうか答えがわかっていないということです。

次に、個別技術に惑わされずDXを実行したいとして、日本独特の商習慣、具体的にはITがベンダーに丸投げという記載に差し掛かります。アメリカはユーザー企業の中にIT技術者を抱えているから、DXをスムーズに進めやすいんだそうです。情シスと事業部門が一体となって計画できるし、CIOに丸投げにせずCEOも主体的にDXに参加できると。一方で、日本はITベンダーのほうが強いので、ユーザー企業がいいなりになりDXが遅々として進まないそうです。ウォータフォール型で要件定義から進めようとするから、そもそもどうDXを進めるかを、ベンダーに決めてもらわなければいけないのがおかしいとのこと。このあたりからDXというより、ベンダー丸投げ中心のIT統制が、システムのレガシー化(いわゆるブラックボックスとなり、保守運用・システム更新コストが高くなる)してしまうそうです。ここまで来ると、DXやるやらないより、まずITベンダーを解散してユーザー企業にばらまいた方が効果的であるかのように見えます。

レガシー化をどう防ぐかということもたくさん書かれていますが、

諸外国のようにユーザ企業が社内に IT エンジニアを抱えて、開発を主導している場合は、高頻度でかつ小規模に(細かく)プログラムをメンテナンスしつづける形態が一般的になる。短期間でメンテナンスを行い続ければ、結果的にブラックボックス化は起こりにくい。個人が持つノウハウもメンテナンスによって他のエンジニアに伝承しやすくなる。

というのは違うかなあと思います。構成管理を正しく行っていれば、ベンダーであろうがユーザーであろうが、その更新頻度にかかわらず、正しく運用できます。ドキュメントがぐちゃぐちゃだと、短期間でごりごり変更すると、「もうソース見て」の世界になります。マイクロサービスやアジャイルをそんなに神格化する必要もないと思いますし、ウォータフォール型でも十分レガシー化は防げますね。

この文書の肝は29ページ以降の「DX 推進システムガイドラインの構成案」にあると思います。これを真に受けるのではなく、下記のように考えるべきだと思います。

・経営者はこの話を聞いて帰ってくる
・ITベンダーがDXでSIを売るときはこの話が頭にある
・技術者は要素技術を求められているのではなく、この話のDXが実現目標にある

どの立場にいても、共通認識があれば大きく話はずれません。その意味では現実解としてこのガイドラインがあると思います。もっとかみ砕きましょう。

・経営者は、会社とITの関係を大きく見直す覚悟があるか。ないのならば、レガシーシステムを普通にシステム刷新していけばよく、そこに最新技術を組み込めばよい。これはDXではないが、技術的負債を解消することはできる。
・ITベンダーがDXを顧客に問いかけるときは、顧客のビジネス自体に切り込む覚悟が必要。場合によっては顧客に常駐しコンサル的な動きをする必要がある。また単にSIとしてこれを提供すると、「DXにふさわしい新しいビジネスを提供する」というかなり高度なサービス目標であり、達成されず検収できないリスクが大きい。じゃあ準委任か・・となり、いつまでたってもDXにたどり着かないダラダラしたプロジェクトになる可能性が高い。
・技術者は、DXという単語がプロジェクト概要に入っていたら警戒すること。アジャイルやIoT、AIなど流行りの技術が盛り込まれているのがDXとユーザー側が思い込んでいる可能性がある。どんなに最先端の技術であっても、結果を産まないシステムを作らされるのは、それこそ苦痛だ。

と言うことです。どうせ無視できないなら、この文書を先読みしておき、自分が本来の目的にリードしなおせるならば勝ちです。否定から入るのではなく、主体的に本来の目的に是正していくことでイニシアチブが取れ活躍できます。意思決定者はそもそもDXがやりたいのではなく技術的負債を清算したいだけなのかもしれません。経営者も特定のITベンダーと仲良くやっていきたいのかもしれません。また、システムごとにITベンダーをころころ変えるやり方が正しいとも思えません。自社にIT技術者がいることがアジャイルやマイクロサービスの本質であるのであれば、アメリカ流のDXをどう解釈しようと日本にピッタリ当てはまるはずはないと思います。

これ読んでおけば「おお、お前わかってるじゃないか」って経営者から評価されること間違いないです。技術ばかり追いかけるばかりが技術者ではないとも思います。

 

補足

基本的に、意思決定者が何か(えらそうに)しゃべるときって、元ネタが絶対にあります。であれば元ネタを徹底的に理解しておけば、それに対してもっと良い意見を主体的に披露し、本来あるべき姿へ自分からリードできるようになります。今回のように、政府やシンクタンク、日経新聞などから元ネタ的なレポートが出るときがあるので、逃がさず目を通しておくといろいろと有利に進められるのでお勧めします。

案外元ネタが穴だらけなことも多く、分量が多ければ多いほどその傾向が強くなります。また、ベンダー企業の利益誘導もされていることもあります。事前に著者も含めてチェックしておけば、本質を突くことができると思います。

 

3ステップで実現する デジタルトランスフォーメーションの実際

データセンター停電時の動作がさくらインターネットの障害報告で理解できる

f:id:orangeitems:20180906105626j:plain

 

北海道震度6強(訂正:震度7)と停電

北海道の大地震はたまたまこの時間に目が覚めてしまったので、リアルタイムでテレビで進行状況を見ていました。今回、地震自体の被害も甚大なのですが、これにより引き起こされた停電によって、北海道全域に影響が及ぶことになってしまったようです。

 

mainichi.jp

北海道電力によると、全道での停電のきっかけとなったのは苫東厚真発電所(厚真町)の発電量低下で、午前6時現在、北海道内すべての約295万戸が停電しているという。また、泊原発(泊村)の非常用ディーゼル発電機は6台あって10日間もつといい、補給用に軽油を手配しているという。道内5カ所の水力発電所は現在復旧した。

 

さくらインターネットのデータセンター一部に影響

この停電の影響で、サーバーのホスティング等を北海道で実施しているさくらインターネットのデータセンターの一部に障害が発生したそうです。

 

support.sakura.ad.jp

発生日時 : 2018年09月06日03時08分 - 2018年09月06日07時44分

影響範囲 : さくらの専用サーバ 石狩第2ゾーンの一部

以下のIPアドレス範囲に含まれるさくらの専用サーバをご利用のお客様

       153.127.106.*
       153.127.107.*
       153.127.108.*
       153.127.109.*
       153.127.110.*
       153.127.140.*
       153.127.141.*

障害内容 : 一部の電源設備において障害が発生しております。
一部お客様サーバーへの接続が行えない状態となっております。
---------------------------------------------------------------------
2018年09月06日

03時42分 : 影響範囲を更新いたしました。引き続き、詳細な状況の確認および復旧作業を続けております
04時10分 : 件名, 影響範囲, 障害内容を更新いたしました。引き続き、復旧作業にあたっております
05時13分 : 影響範囲にIPアドレスを掲載いたしました。引き続き、復旧作業にあたっております。誠に恐れ入りますが、今しばらくお待ちいただけますと幸いです。
05時16分 : 障害内容を更新いたしました。お客様には多大なご迷惑をおかけしていること、お詫び申し上げます。

05時53分 : 現在の状況についてご報告申し上げます。さくらの専用サーバの給電回路を収容している一部のUPSにおきまして、停電に伴う電源切替時に動作異常が発生したことが判明いたしました。この影響により、上記IPアドレスのさくらの専用サーバにつきまして、現在も接続できない状態が継続しております。現在、UPSの復旧作業、およびその他の方法による復旧策の検討を進めております。

07時02分 : UPSの復旧および電源回路の変更による復旧に向けて作業を進めております。ご迷惑をお掛けしておりますこと、お詫び申し上げます。

07時44分 : UPSの機能を回復し、給電を再開いたしました。現在、サービス復旧の確認を進めております

08時04分 : サービスの回復を確認いたしました。長時間に渡りご迷惑をお掛けしましたこと、深くお詫び申し上げます。

 

データセンターにおける自家発電設備への切り替え方法

我々は空気のように電力を使いますが、今回の地震や昨日の台風のように、停電と隣り合わせです。データセンターは電力ありきで動いているのですがその上のサーバーは絶対に電気が24時間途切れなく供給されることを前提として動いています。もし、1秒でも電気供給が途切れたら、サーバーは再起動してしまいます。システムはサーバー一台ではなく複数のソフトウェアで連動して動いていますから、大規模なシステム障害につながってしまいます。

最近のほとんどのデータセンターは、したがって自家発電装置を装備しています。停電時には自家発電装置に切り替えて、こちらに燃料(原油など)を定期的に供給し停電のない環境を保証しようとしています。今回もこの自家発電装置への切り替えにおいて問題が発生したということになります。

記事を書いている2018/9/6 11:00AM現在、さくらインターネット石狩データセンターにおいては自家発電装置での運用が継続しているそうです。

 

support.sakura.ad.jp

発生日時 : 2018年09月06日03時08分 -
影響範囲 : 石狩データセンター収容サービス
影響内容 : 現在、弊社石狩データセンターへの北海道電力による特別高圧送電が
停止(停電)しております。石狩データセンター収容サービスにつきま
しては、自家発電設備により正常に稼働を継続しております。

 

 

さて、それでは、サーバーが電力会社から供給されている電力を利用するためのコンセントにつながっているとします。サーバーは動いています。横に、自家発電装置用のコンセントがあるとします。どうやって差し替えますか?。コンセントを抜いて、新しいコンセントに指しますか?。そうすると電源が落ちてしまいます。ここで登場するのが「UPS(Uninterruptible Power Supply)」です。

無停電電源装置 - Wikipedia

サーバー類は、電力に直接つながっているわけではなく、UPSにまずつながっています。UPSに対して通常は電力会社の電力が接続されています。もし電力会社の電力が停電等で供給されなくなった場合、UPSの中のバッテリー電源が利用されるため、サーバーから見ると電力は供給され続けます。

問題は、UPS自体は、何時間も持たないことです。データセンター全体の電力を何時間も賄えるようなUPSは存在しません。持って数十分でしょう。その間に何をしなければいけないか。データセンターのオペレーターが、自家発電装置をまず起動すること。そのあとにUPSの電源供給を切り替えること。これらを迅速に実施しなければいけません。

なかなかシビアな状態だと思います。人的ミスもありえますし、自家発電装置がうまく動かないかもしれない。今回のように、UPS自体に障害が発生するかもしれない。

実際に停電状態になることは、通常時にはほぼないので、普段は机上の訓練などを行っていることと思います。しかし、それ通り実施したとしても、今回のようにうまく動かないこともある。これが、データセンターの現場における停電時の対応に関する運用の難しさだと思います。

今回のさくらインターネットのケースでは5時間弱で回復したわけですが、データセンター設備のエキスパート含め深夜に緊急出動した結果であろうと思います。通常運用に戻るにはまだ通常電源への切り戻しも含め予断を許さない状況にあろうと思いますが、関係者の奮闘をお祈りします。

 

※この過去記事でさらに理解が進みます。

停電時のデータセンターの対応 – さくらインターネット研究所

 

 

一方で、データセンターはやはり複数持つべきだなと痛感します。台風、地震と、これだけ短期間に大災害が発生すると、シングルデータセンター設計は危険だなと思う次第です。AZ(アベイラビリィティーゾーン)というよりは、海外にバックアップデータセンターを作るなど、どちらかと言えばDR(ディザスターリカバリー)の概念です。日本のデータセンターは半分は関東にあるというデータもあり、たまたま関東が被害を受けていないからまだ静かですが。業界の潮目が変わりそうな今回の件です。

 

追記

通常状態に戻るまでの記事です。

ascii.jp

確かに奇跡と呼んでもいいと思います。日々の訓練や手順・体制の準備の賜物だと思います。関係者の皆様ありがとうございました。

 

 

クラウド&データセンター完全ガイド 2018年春号

 

継続するには覚悟がいるという話

f:id:orangeitems:20180903181800j:plain

 

私の仕事の状況

私は、とあるクラウドサービスに特化してインフラ基盤を提供するような仕事を数年前からずっと続けています。右肩上がりで伸びた時期もあったのですがここ最近は停滞気味、と言ったところです。クラウドサービスと言っても世の中にはたくさんあり、今一番強いところはAWS、二番目がAzureです。二つのサービスの躍進を見ながら、耐えて耐えて、とあるクラウドサービスに特化してビジネスをしている状況です。

AWSやAzureの最近の伸びはすさまじく、なんとなく、ああ私もあっち側に言っておけばよかったかなあと思う時があります。例えば、パン屋だとして、メロンパンとカレーパンがバカ売れしているのに、私は焼きそばパンです。焼きそばパン専門店なので、メロンパンとカレーパンは作りません。もう焼きそばパン屋もやりながらメロンパンもカレーパンも作っちゃおうかなという迷いが生まれます。

そこであえて、メロンパンもカレーパンも作らないという選択をやってきました。メロンパンもカレーパンも売れるなら、焼きそばパンもいつか売れるだろうという判断です。私の目からみて、AWSやAzureは先行者がいて、そして多数のベンダーが殺到していてレッドオーシャンになっているように見えたからです。今更AWSやAzureに手を出しても、もっと優秀なベンダーがいて彼らには勝てないだろう。参加者も多いので単価も厳しそうだし、いろんなクラウド基盤に手を出すとどこかで「ドハマリ」して、売りだった焼きそばパンが売れ出した時に、手が回らないということが起きるだろう。そんな判断をしています。

焼きそばパンが一定時期売れなかったとしても、焼きそばパン一筋〇〇年、という看板というのは大事で、いざ売れた時に実はAWSもAzureも手を出していて手薄になっていると、本当のビジョンである焼きそばパンの大手にはなれないわけです。

 

マーケティング的な話

ここまで来るとマーケティングの話になりますが、ある市場において勝ち組になるためには、市場が小さいうちにシェアを大きくしておくのが最善です。まだ競争相手が少ないし、先行者もいないに等しいのでとにかく参入し、活発に活動してイニシアティブを取ってしまいます。その後、市場が劇的に伸びるときにシェアを維持していけば、市場の成長とともに自社が成長します。先行者になれるので、他社も入りにくく、これぞブルーオーシャンと言えます。

市場が大きくなってしまったら、参入するのが大変になります。3大キャリアに参入しようとした楽天が6000億円の設備投資が必要だという話がありました。市場が10分の1だったらその10分の1で参入できたはずです。そして、総務省の肝いりで作られたMVNO市場は多数の業者が入り乱れており、ビジネスとしてきちんと黒字を出せている要は数少ないと聞きます。こういうふうに、参入しやすいとレッドオーシャンになるし、参入しにくいとブルーオーシャンなのですが仲間に入るのが相当大変です。

私の迷いとしては、「焼きそばパンブームは来るか」ということです。AWSやAzureがこのまま突っ走ってしまい、他のクラウドを駆逐するような時代がやってくるかということです。私の見立ててではそんなことはないと思っています。何社かの寡占状態にはなると思うのですが、2社だけにはならないと思います。クラウドサービス自体もいろいろな技術革新で仕様も変わるでしょうし、後発の方が有利な場合も生まれると思います。昨今で言えば、量子コンピューター、電源を停止しても消えないメモリ(パーシステントメモリ)、SSDの大容量化、ネットワークは5Gの登場など、10年後は大きく変貌していると思います。2社独占というのは考えにくいかと思います。・・・と思って虎視眈々と焼きそばパンブームを待っているのですが、なかなかAWS/Azure強し。メロンパンやカレーパンは良く売れるなあ。

儲からない定食屋にありがちなのがメニューがやたら多いと説があります。AWSが流行っているからAWS、それでも仕事が来ないからAzure、やっぱりGCPなどなど手を出しまくって、ビジネスのポートフォリオがまだら模様になっていると、同じように成功しないのでしょう。ただ、この理論に基づいて、選択と集中をやったとして、失敗するケースがあります。やっぱり焼きそばパンが一向に売れないときです。

 

これはよくある話だと思う

一筋でやりきるのがいいのか、それともあきらめて次に行った方がいいのか、これはビジネス上最も大事な判断だと思います。ベンチャー企業の社長の語る夢を、成功するまで手伝った方がいいのか、それともこの人の言っていることは一生達成しない、転職したほうがいいのか、はてなブックマークを見ているとそんな葛藤が良く見られ、共感しています。

私自身は初めのビジョンを貫徹し、より継続する方にかけたいと思います。だんだん、「気合」「信念」みたいな精神論も必要になってくるぐらい、うまくいかないと大変な思いをするわけですが、がんばるしかないですね。私が立てたビジョンなんだから、うまくいくまで自分が折れちゃだめだなと。

どんなにビジョンが論理的に正しくとも、それが現実に反映されるまでに、1年なのか5年なのかそれとも先進的過ぎて100年かかるのか、それとも全然的外れで反映は絶対しないのか、それは実は達成されるまで誰にもわかりません。それを達成するのは、きっと今では好まれない精神論も、きっと必要なんだろうなと思います。

私はぶれずに当初のビジョンを語りその通り行動していきたいと思います。

(・・・こんなことをわざわざ書くということは、なかなか焼きそばパンがうまく売れず、自分を励ましているだけなんですけれども(笑))

 

組織改革―ビジョン設定プロセスの手引

 

 

Javaの歴史的転換点となる2018年9月となりました | わかりやすくまとめる

f:id:orangeitems:20180902123052j:plain

  

今月は歴史的転換点

これまでこのブログでも何度もお伝えしてきたように、Java SEをめぐっては大きくリリースモデルが変わります。その変わり目が今月、2018年9月です。現場においては準備は完了しているのでしょうか。

 

ざっくり言って

たくさん報道されているので、訳が分からなくなっている人も多いと思います。要点をズバリまとめていきます。

全ての根源はOracleが展開している下記の表に基づいています。

f:id:orangeitems:20180902114901p:plain

Oracle Java SE Support Roadmap

 

Oracle Java 7/9はもう無償アップデートされていない

上記の表には、「商用ユーザーの公開更新の終了」という欄があると思います。こちらにおいて、バージョン7と9は過去の日付になっていますよね。

したがって、ダウンロードサイトにも、もう7と9はダウンロードできないようになっています。

Java SE - Downloads | Oracle Technology Network | Oracle

現時点で、8と10だけしかダウンロードできませんから、7と9はもう使うなということはわかると思います。

 

Oracle Java 8は2019年1月までで公開終了

これは良心的だとは思いますが、まだバージョン8のセキュリティーパッチは更新され続けています。最新は、2018年7月17日のu181となっていて誰でも入手可能です。

Java™ SE Development Kit 8, Update 181 Release Notes

このリリースが止まるのが、2019年1月です。これまでに移行を完了させないと、セキュリティーパッチが出ないJavaを使い続けることになってしまいます。

もしくは、6月にOracleが発表した、サブスクリプションへ移行し有償でパッチを手に入れ続けるしかありません。

Java SE Subscription : Oracleから発表された情報まとめ - orangeitems’s diary

 

Oracle Java 10は2018年9月までで公開終了

気の早い話ですが、2018年9月でOracle Java 10の公開が終了します。バージョン7や9と同じ扱いになるということです。ダウンロードすらできなくなります。

 

Oracle Java 11からライセンスが大きく変わる

2018年9月26日にOralce Java 11がリリースされたのですが、Oracleのサイトから入手可能になっています。なぜダウンロードがまだできるのか・・このからくりは、ライセンス変更にありました。

(重要)Oracle Java 11から、ライセンス契約の内容がガラリと変わっています | 無償利用は非商用・開発用途のみ - orangeitems’s diary

非商用・開発になら使ってもいいよ、ということだけの話だったのです。

 

つまり

OracleのJava SEダウンロードサイト(一般公開)から、今月でJava 10が消えます。そして来年1月にJava 8が消えます。そしてJava 11以降は今後も公開されますが、ライセンスの大幅変更により、商用利用できません。

 

今後どうすればいいかをざっくり

Oracle純正のサブスクリプションなどの有償プランで延命するのが最も無難ですが、実質無償で使い続けてたい人向けにざっくり方法を書いておきます。

 

・OpenJDKで半年ごとにバージョンアップすることに慣れる
・Linuxであれば、有償ディストリビューションに含まれるOpenJDKを使い、OSのサポート期間使い続ける(RedHatなど)

 

どちらかしかないかなと思います。詳細は以下にまとめています。 

2018年9月現在のJavaサポート状況をまとめる - orangeitems’s diary

 

今月Java 11がリリースされますが、OpenJDK 11にて、LTS(長期サポート)の言及があるかどうか。ここに焦点が移るだろうと思います。望み薄な気がしています。

  

 

増補改訂版 Java言語で学ぶデザインパターン入門

GitHubで継続的に発生している大規模インシデント | 便利と危険は裏返し

f:id:orangeitems:20180830161022j:plain

 

GitHubから情報漏えい

中国の大規模な情報漏えいのお話です。


www.itmedia.co.jp

技術情報サイトのBleeping Computerは8月28日、中国の大手ホテルチェーンHuazhu Hotels Group(華住酒店集団)の利用客1億3000万人あまりの個人情報が、中国のダークWebフォーラムで売りに出されていると伝えた。

(中略)

Bleeping Computerは、中国のセキュリティ企業Zibaoが地元メディアに語った内容を引用して、Huazhuの開発チームが誤ってデータベースのコピーをGitHubアカウントにアップロードしたことが原因だったようだと伝えている。

 

GitHubはマイクロソフトが買収することが決まっている、ソフトウェア開発者向けのソースコードホスティング基盤です。ソースコード管理ソフトウェアであるGitをインターネットでサービスとして提供しているのが特徴です。

無料版を使う場合は、ソースコードが公開され、第三者が参照することができます。人気のプロジェクトはスターをもらうことができ、オープンソースソフトウェアとして世界の人々が便利に使うことができます。

 

employment.en-japan.com

 

こうやって見ると、ソースコードだけではなく、有用なサイトや動画のリンクやドキュメントなど幅広く利用されていることがわかります。

企業のソフトウェア開発など、ソースコードを非公開で管理したい場合は、有料版に移行して使うというサービスです。

 

GitHubからの漏えい事件

便利なGitHubなのですが、使い方を間違えるととんでもない状況となります。

 

AWSにアクセスするアクセスキーペアを抜かれちゃう問題

アプリケーションにて、AWSリソースにAPIでアクセスするような処理をソースコードに書いたとします。もちろん、アクセスキー ID とシークレットアクセスキーが埋め込んであります。GitHubにアップロードすると何が起こるでしょうか。

なんと、常にGitHubをクロールする悪者がいて、アクセスキーを入手されてしまうのですね。

実際に試された方がいらっしゃいますのでご参考まで。

 

qiita.com

GitHub にはアクセスキーを検索するBOTが常に動いていて、公開するとすぐに抜かれて不正利用される 的なコメントがつくのを何度か目にしたのですが、
本当にそんな BOT が動いているの?
どのくらいの時間でキーを抜かれて、不正利用が始まるの?
というのが気になったので、検証してみました。

 

結局のところ、認証を埋め込んでいるようなソースコードを公開するなよ、というのが本筋なのですが人間がやることなので怖い話だなと思いました。

AWS自身がクロールしていることも含めて、人間自身が脆弱ですね。

 

Appleですらやらかした件

Appleと言えば、優秀な開発者集団のように思いがちですが、iOS(iPhoneのOS)の一部ソースコードをGitHubに公開しちゃったという話です。

 

www.itmedia.co.jp

米AppleのiOSのソースコードの一部が流出し、何者かがGitHubで公開していたことが分かった。問題のコードは、その後Appleの要請に基づいて削除されたが、脱獄(Jailbreak)などに利用される可能性も指摘されている。

 

優秀かどうかに関わらず、人間には、勘違い、思い込み、不調など、脆弱性が埋め込まれていて、それが発現するとインシデントとなってしまうのは法則のようです。気を付ければ大丈夫、と思っている時点で、気を付けなければこのような大問題になってしまいます。フェールセーフという言葉がありますが、失敗しても安全に倒れるようにしないとこのGitHubというサービスは危険だなと思った次第です。

 

非公開がハッキングされたウーバー

非公開なら安全だよね、というのもまた思い込みですね。

 

www.bbc.com

ウーバーはハッキングの具体的な詳細について確認していないが、ブルームバーグの報道によると、2人のハッカーが開発者向けのオンラインサービス「GitHub」の非公開部分に侵入した。
ハッカーはそこから、企業がデータ保管に使うクラウドサービスを提供するアマゾン・ウェブ・サービス(AWS)のウーバーのログイン情報を見つけたとみられている。

 

非公開というのは、裏を返せば何らかの認証情報を持ってアクセスできるということになります。その認証の強度や、破られた時のリスクを把握しコントロールしないと、とんでもない状況に陥ると言えます。

 

オープンソースが改ざんされたという話

例がたくさんあるので、この際挙げておきます。

 

nanashi0x.hatenablog.com

6/28(木)、Gentoo Linuxが所有するGitHubアカウントが悪意を持つ何者かに乗っ取られた事がわかった。
Gentoo LinuxディストリビューションのGitHubアカウントへのアクセスを管理していた個人が元のソースコードを悪意のあるコードに置き換えたのだ。

 

あまり日本ではなじみのないLinuxディストリビューションであるGentoo Linuxですが、このGitHub上のオープンソースを乗っ取られて、マルウェアを仕込まれてしまったという件です。

Linuxベースのデバイスやシステムを作る時に、GitHubからインストーラーをダウンロードしインストールしますが、この時点でマルウェアが混入されるとユーザーはたまったものではありません。個人情報を不意にアップロードされたり、システムが急停止するなど影響は甚大です。

 

なお、対策はもう取られているそうです。

nanashi0x.hatenablog.com

Gentooが攻撃を受けて取った再発防止策は以下の通りです。
・定期的なGitHub Organizationのバックアップ
・2段階認証のデフォルト化
・インシデント対応計画の作成
・未使用アカウントの削除
・高い権限を持つユーザを減らす
・ログインの監視
・パスワードマネージャーの使用
・ハードウェアベースの2段階認証

 

生産性の前に、リスク評価を

世の中が、生産性重視に走っていることは間違いありません。

でも、リスクを無視してまで優先する生産性なんてありはしないのです。リスクを一生懸命考えて、考え抜いて、それでコントロールするのであれば一つ、アセスメントの方法としてはふさわしいと思います。また、生産性を犠牲にしてでも使わないというのも立派なアセスメントです。

便利なツールが出て、それをどんどん使って生産性向上をしたら、先端的でかっこいい、という短絡的なビジョンで突っ走る技術記事も多数散見されます。

おかげで、何億人の人々の情報が晒されてしまうということが、日常茶飯事になっています。

過去の慣習にとらわれることは合ってはいけないですが、過去の慣習だからといって価値を低く見積もるのも考え物だと思います。何を採用するにしても、リスクの評価は一番にすべきだと思います。

GitHubにしても、「こうすれば防げた」という対策がたくさんあるのですが、そもそもそのような対策をデフォルトとしそれ以外の設定では利用できないようにするべきです。今日にいたっても1億3000万人の情報漏えいが起こっている事件を聞くと、私ならリスクがまだ高いと判断しますね。個人的には、自分でサーバーを借りてGitを自前ホスティングしたほうがまだ安全かと思います。

 

わかばちゃんと学ぶ Git使い方入門〈GitHub、Bitbucket、SourceTree〉