セキュリティ担当者はつらいよ 組織間で発生するギャップにどう立ち向かうか(転載)

cover_news015.jpg


 本連載は、組織のセキュリティ体制を整えてきた筆者の経験から「セキュリティにおいて大切なもの」「セキュリティで起きがちな課題」「安全な組織とは」などをさまざまな切り口で考察するものだ。

 しばらく間が空いてしまったため、前回のおさらいから始めよう。前回の最後でサイバー攻撃に対応する関係者は、組織階層により目的や考え方、求められるミッションが異なるため、折り合いをつけることが困難な場合があるという話をした。

 こうした立場による認識相違は組織階層に限った話ではない。第2回は、セキュリティシステムを利用するユーザー側とサービスを提供するベンダーの開発部門、さらにベンダーの運用部門の立場から、サイバー攻撃を防いだ後に発生する可能性がある「認識相違」について説明する。分かりやすくするため事例は「あえて極端な例」を挙げていることに留意してほしい。

想定通りにインシデントを未然に防いでいるのに…… なぜ「立場による認識相違」が発生するのか


 多層防御やゼロトラストモデルなど被害を予防するセキュリティ対策によって、想定通りにサイバー攻撃を防御をしても、システム担当部門やCSIRT担当者にとって頭を抱えるケースがある。

 今回の例は、Webサイトに悪意のあるファイルアップロード攻撃が実行されて、それをセキュリティシステムがブロックしたケースを想定する。Webサイトは、簡略化しているが「分散型サービス妨害(DDoS)攻撃」「ファイアウォール(FW)やIPS(不正侵入防止システム)、Web Application Firewall(WAF)」「サーバ自身のマルウェア対策」などの多層防御を実装しているものとする。サイバー攻撃に対する階層ごとの挙動は以下だ。

  1. DDoS対策:しきい値の超過などの異常がなく通過
  2. FWなどの対策:通常アクセスとみなされ通過
  3. マルウェア対策:不審なファイルのため駆除
 今回のようなWebサイトにサイバー攻撃を受けた場合、マルウェア駆除検知がトリガーとなり、Webサイトの運用部門から開発部門のシステム担当に連絡が入る。システム担当は「サイバー攻撃を本当に防御できたかどうか」「他のシステムに攻撃を受けてないか」などの調査と並行し、自社の上席やユーザーである顧客にサイバー攻撃を受けた旨や対応方法について報告する、という流れが一般的だ。

 現場のシステム担当からすれば、Webサイトのセキュリティ対策は想定通りに動いたため「大きな問題は発生しなかった」と考えるだろう。一方でサービス提供ベンダーの経営層やユーザーはどのように考えるだろうか。極端だがそれぞれの立場におけるサイバー攻撃の対処への反応を下図にまとめた。


 現場のシステム担当者は、運用ルールに従ってユーザーに連絡しても「(想定通り機能したのであれば)夜中に電話をするな!」と怒られて、自社の経営層からは、リリース以前に報告していた通りの対策であるにもかかわらず「(多層防御のうち何枚かは破られているため)新たな対策を追加せよ!」や「攻撃を受けること自体を防げ!」など厳しい注文を受けることもあるだろう。そしてそのしわ寄せは、末端に位置するシステム運用部門に集まることも多い。読者の中には、立場にもよるが同様の経験をしている人も少なからず存在するのではないだろうか。

考え方は立場や企業に応じて異なる 分かり合えないならせめて


 先に挙げた例での立場による見解の違いは、費用や契約の問題から生じることが多い。根本的な問題のため、関係者全員が納得するのは難しいかもしれない。

 システム担当者は、自社の経営層の意見については経営としての高度な視点と真摯(しんし)に受け止めて、この事態を糧に運用部門と協力して運用の実態を踏まえた上で適正コストを見積もるなどいい意味での「鈍感さ」を持つべきだろう。

 ユーザーに対しては次なる対策を提案する契機と捉え、今回のサイバー攻撃が不成立であっても今後は成立する可能性があるとして、インシデントの発生を想定したアドバイスを提言してもよい。プロとしてふるまい、ユーザーのさらなる信頼を勝ち取るように努めるべきだろう。



2020年下半期に公開されたセキュリティ関連文書まとめ(転載)


2020年下半期に公開されたセキュリティ関連文書まとめ

政府機関

高度情報通信ネットワーク社会推進戦略本部(IT総合戦略本部)

文書タイトル公開日
デジタル・ガバメント実行計画2020/12/25

セキュリティ関連団体

JNSA

文書タイトル公開日
電子署名Q&A2020/09/16
中小企業において目指すSecurity By Design2020/11/05

 


「情報セキュリティ10大脅威 2021」を決定(転載)


「情報セキュリティ10大脅威 2021」を決定:

IPAは情報セキュリティ対策の普及を目的として2006年から、前年に発生した情報セキュリティ事故や攻撃の状況等から脅威を選出し、上位10位を公表しています。本日公表した「情報セキュリティ10大脅威2021」は、IPAが2020年に発生した脅威候補を選定し、情報セキュリティ分野の研究者、企業の実務担当者など約160名のメンバーで構成する「10大脅威選考会」の投票を経て決定したものです。

個人の順位では、昨年に引き続き、「スマホ決済の不正利用」が1位となりました。スマホ決済サービスを悪用して他人の銀行口座から残高をチャージ(他人の口座からの金銭窃取)する事案などが引き続き発生しています。スマホ決済サービスの利用者は、二要素認証を利用するなどの不正ログイン対策の実施や、被害を受けた際に早期に気付くことができるように、スマホ決済サービスの利用状況を確認することが重要です。また、スマホ決済サービスの利用者以外でも、スマホ決済サービスと連携可能な銀行口座を持つ人は被害に遭う場合もあるため、口座からの出金履歴を適宜確認するといった心構えが重要です。

組織の順位では、「ランサムウェアによる被害」が1位となりました。昨年8月にIPAは、ランサムウェアを用いた新たな攻撃の手口として「人手によるランサムウェア攻撃」と「二重の脅迫」について注意喚起を行いました。従来はウイルスメールをばらまくなどの方法で広く無差別に攻撃が行われていましたが、新たな攻撃者は、明確に標的を企業・組織に定めています。標的型攻撃と同様の手法で企業・組織のネットワークに侵入したり、データを暗号化するだけでなく窃取して公開すると脅したりして、身代金を支払わざるを得ないような状況を作り出します。昨年は国内企業への攻撃も報道され、大きな話題となりました。新たなランサムウェア攻撃は、標的型攻撃と同等の技術が駆使されるため、例えば、ウイルス対策、不正アクセス対策、脆弱性対策など、基本的な対策を、確実かつ多層的に適用することが重要です。

また、「テレワーク等のニューノーマルな働き方を狙った攻撃」が初登場で3位となりました。昨年は新型コロナウイルス感染症の世界的な蔓延に伴い、感染症対策の一環として政府機関からテレワークが推奨されました。テレワークへの移行に伴い、自宅などからVPN経由で社内システムにアクセスしたり、Web会議サービスを利用したりする機会が増えました。また、私物PCや自宅ネットワークの利用や、初めて使うソフトウェアの導入など、以前までは緊急用として使っていた仕組みを恒常的に使う必要性がでてきました。こうした業務環境の急激な変化を狙った攻撃が懸念されています。基本的な対策のほか、テレワークの規定や運用ルールの整備、セキュリティ教育の実施などが重要です。

【2021年1月】株主優待戦略を考える(権利付き最終日:2021年1月27日 )


2020年1月の株主優待戦略を考える。

自分にとってはJALマイルの獲得が行動の源泉となっているため、プレミアム優待倶楽部の中から対象を絞り込んでいくこととなる。

優待取りで株式を取得して損失を出してしまっては元も子もないので、まずは下記のポイントで絞り込みを実施

①プレミアム優待倶楽部の9月権利確定企業の一覧を確認
 ⇒継続保有条件ありやポイント付与終了の企業は脱落

②証券会社のWebサイトにアクセスし、空売りが可能かを確認
 ⇒空売りできない銘柄は脱落

株主優待情報サイトにアクセスし、最も効率の良い投資対象を選定

上記の絞り込みの結果、なんと今回は条件を満たす企業がなかった。

それで終わりにするのは少しもったいないので、前回12月の優待取りの際の改善を検討してみる。

両建てで優待取りを行う場合、理屈上はプラスマイナスゼロとなるが、実際は取引手数料だったり貸株料だったりで細かいマイナスになっている。

なので、これらも含めて株主優待を取りつつも多少なりとも利益もとれるような両建てを検討してみたい。

何もネタがないと議論のしようもないため、1月に優待取りが可能で、且つ両建ても可能な鳥貴族(3193)をベースにいろいろ試行錯誤を重ねたいと思う。

1年前の振り返りとなるが、2020年1月の優待取りについては権利落ち日が1/29であった。

となると、前日の2020/1/28の株価で判断することとなるので、当時の情報を集めてみる。

【2020/1/28 鳥貴族(3193)
始値:2551
高値:2595
安値:2549
終値:2588

日足ATR:62
30分足ATR:13

※いずれのATRもローソク足20本分としている

基本的に優待取りなので、必ず約定させる必要が出てくる。

しかし成行だと始値で約定してしまい、指値だと刺さらないリスクが出てくる。

そこで、「不成」という、指値で刺さらない場合は前場の終値で成り行き注文に変更するという注文方法を取ってみる。

この方法でポイントとなるのが30分足のATRと踏んでいる。

仕掛けだが、前日終値と30分足のATRを使い、下記のように試算してみる。

【2020/1/29 鳥貴族(3193)仕掛け案
ロング:2575円以下で約定(終値2588-13(30分ATR))
ショート:2601円以上で約定
(終値2588+13(30分ATR))
※約定できない場合は前場終値で成行注文

さて、結果はどうであっただろうか?

Trading Viewの30分足でシミュレーションしてみる。。。。

【2020/1/29 鳥貴族(3193)結果
ロング:2575円 ※指値で刺さる
ショート:2496円 ※指値刺さらず、前場終値の成行注文で約定

ちなみに、1/29の結果は下記である。

【2020/1/29 鳥貴族(3193)
始値:2581
高値:2588
安値:2476
終値:2476

前場終値:2496
30分足ATR:18

つまり、持っているポジションは下記の状況となる

ロング:2575円(▲99)
ショート:2496円(20) 

で、手仕舞いに向けてどう考えるか。

ルールを仮で作ってみる。

【仮ルール】
・目標価格を約定金額±1ATRで設定
・すでに2ATR以上利益が出ている場合は成行

で、このルールに乗っ取って、手仕舞案を考える

【2020/1/30 鳥貴族(3193)手仕舞案
ロング:2593円以上で約定(約定価格2575+18(30分ATR))
ショート:2478円以下で約定
(終値2496-18(30分ATR))
※約定できない場合は前場終値で成行注文

改めてTrading Viewの30分足でシミュレーションしてみる。。。。

【2020/1/30 鳥貴族(3193)結果
ロング:2593円(18) ※指値で刺さる
ショート:2478円(18) ※指値刺さる

ロングとショートでそれぞれ100株ずつ仕掛けた場合、1800*2で3600円程度の利益が生まれる。

ほんまかいなって気がしなくもないが、2020年の結果を踏まえるとこういう結果となる。

実はロスカットラインも設定してシミュレーションしてみたのだが、今回の場合はロスカットラインを設定することでかえって損失が大きくなってしまった。

ロスカットラインの設定をしないと小次郎講師に怒られそうだが、今回の場合前場で手仕舞ってしまうため、ある意味価格ではなく時間によるロスカットラインを引いているとも言えなくもない。

しばらくトライアンドエラーで両建ての塩梅を探ってみることとする。

【1/26】
ついに明日は権利落ち日。

下記で仕掛けをしてみる。結果はまた明日。。。


【1/28】
手仕舞完了。

結果は散々たるものだった。

まず、下記が結果、12月同様、3万円近くも損失を出してしまった。


・反省点①:
成り行き注文はアブナイ

鳥貴族(3193)の前日終値が1505円、約定価格1482円で23円の含み益があったため、成行で約定注文を出した。

ところが、翌日窓が開いて、始値が1475円となり、成行注文をしたがために7円のマイナスとなってしまった。
↑鳥貴族(3193)の30分足

[教訓]前日終値ベースで含み益が出ていても、成行注文で利益確定を図るのは危険


・反省点②:ロスカットラインは設定すべきか

チャートを見れば一目瞭然なのだが、チャートは完全に右肩上がりである。

この状況でトレンドと逆方向に仕掛けてロスカットラインを設定しなかったのはやはりリスクが高かった(それでも不成注文で多少ヘッジできたが‥‥)

ロスカットラインは利確チャンスを削ぐリスクがあるため、すごく悩ましい。。。。

ロスカットラインは引き続き検討するにしても、成行注文で利確を図る行為はやめよう。。。

日産北米法人のアプリなどのソースコードが流出 / Nissan Source Code Compromised Online Due to Exposed Git Server(転載)~クラウドサービスの利用において、アクセス権設定は肝中の肝であることを改めて認識させられる~


公開されたGitサーバーにより、日産ソースコードがオンラインで侵害されました:
 

日産自動車のソースコードがオンライン上で漏洩したのは、同社がデフォルトのアクセス資格情報で保護されたGitサーバーを公開したままにしていたためだ。このリークは、スイスに拠点を置くソフトウェアエンジニアのティリー・コトマン氏がZDNetとのインタビューで明らかにしたもので、彼女は未知のソースからリークを発見し、同社のデータを分析したという。

ソースコードリポジトリには、「日産のモバイルアプリのソースコード、日産ASIST診断ツールのコンポーネント、ディーラーのビジネスシステムとディーラーポータル、同社の社内コアモバイルライブラリ、車両物流ポータル、市場調査ツール、データ、顧客獲得とリテンションツール、車両接続サービス、複数のバックエンドと社内ツールに関する重要な情報」が含まれていたという。

データが暴露され、トレントリンクやハッキングプラットフォームを介してテレグラム上で共有され始めた後、同社は昨日、Gitサーバーをシャットダウンするという予防措置を取った。メルセデス・ベンツも2020年5月、スイスのサイバーセキュリティ専門家が、同社がGitLabサーバーを誤って設定し、複数のメルセデス・ベンツのアプリやツールのソースコードを流出させていたことを発見した際に、データ流出の被害に遭っていた。

日産の広報担当者は事件を認め、さらに「日産は、会社の専有ソースコードへの不適切なアクセスについて、直ちに調査を実施しました。我々はこの件を重く受け止め、今回のセキュリティインシデントで消費者、販売店、従業員の個人データにアクセスできなかったことを確信しています」と述べています。影響を受けたシステムは安全に保護されており、公開されたソースコードに含まれる情報が消費者や車両を危険にさらすことはないと確信しています」。

攻撃者はGitLab上の同社の公開リポジトリに手を出すことができたが、そこにはトヨタ、サンテック、ペプシ、モトローラ、メディアテック、シエラネバダコーポレーション、米空軍研究所などの大手企業の機密情報を含むフォルダが含まれているが、幸いにもすべてのフォルダには攻撃者を安全な資産に誘導するような機密情報は含まれていないという。

IPA、セキュリティ等について充実を図った「情報システム・モデル取引・契約書」 第二版を公開(転載)

000087499.png

セキュリティ等について充実を図った「情報システム・モデル取引・契約書」 第二版を公開:

背景

デジタル技術を活用して企業のビジネスを変革し、自社の競争力を高めていく「デジタルトランスフォーメーション(DX)」が注目を集めています。経済産業省が2018年9月に公開した「DXレポート」は、DXを円滑に進めるには、ユーザ企業、ITベンダが双方の間で新たな関係を構築していく必要があると提言しています。そのために、DXの進展によるユーザ企業とITベンダのそれぞれの役割の変化等を踏まえたモデル契約の見直しの必要性が指摘されました。モデル契約は、情報システム開発における各局面の取引構造を透明化するためのツールであり、その普及により、ITベンダの産業構造転換、情報システムの信頼性向上、ユーザ・ベンダ一体となった生産性向上の促進が期待されます。

こうした状況を踏まえ、IPAでは、経済産業省が2007年に公開した「情報システム・モデル取引・契約書」、およびIPAが2011年に公開した「非ウォーターフォール型開発用モデル契約書」についての見直しの検討を2019年5月から2020年12月にかけて行いました。この検討では、全体を取りまとめる「モデル取引・契約書見直し検討部会」を設置し、民法改正に対応した「情報システム・モデル取引・契約書」の見直しについては、同部会の下で、ユーザ企業、ITベンダおよび法律専門家から成る「民法改正対応モデル契約見直し検討WG」において検討しました。

同WGでは、2019年度検討の成果として、2020年4月に施行された改正民法に直接関係する論点を見直した 「情報システム・モデル取引・契約書」の民法改正を踏まえた見直し整理反映版 (以下、「民法改正整理反映版」)を、2019年12月に公開しました。その後、民法改正に直接かかわらないものの、2007年のモデル契約の公表以降の情勢変化に応じて見直した方がよいと考えられる論点(後述)について検討しました。なお、論点の一つであるセキュリティに関連する検討については、セキュリティ専門家の意見を求めるため、2019年7月から同WGの配下に「セキュリティ検討PT」を設置して検討しました。

概要

IPAはこれまでの検討を取りまとめ、「民法改正整理反映版」に民法改正に直接かかわらない論点の見直しを加えた「情報システム・モデル取引・契約書」第二版(以下、「第二版」)を、2020年12月22日に公開しました。また、「第二版」から参照されるセキュリティ基準等公表情報の一例として「情報システム開発契約のセキュリティ仕様作成のためのガイドライン」と「セキュリティ仕様策定プロセス」(以下、「セキュリティ仕様関連文書」)を同時に公開しました。

「第二版」は、ユーザ企業、ITベンダ、関連業界団体、および法律専門家の参画を得て議論を重ね、中立的な立場でユーザ企業・ITベンダいずれかにメリットが偏らない契約書作成を目指しているところが特長です。後述のように、民法改正に直接かかわらない論点について、現行のモデル契約条項と解説の修正版、および見直しについての解説を整理しています。

「セキュリティ仕様関連文書」は、セキュリティ専門家、一般社団法人コンピュータソフトウェア協会(CSAJ) Software ISAC等のセキュリティ関連団体の参画を得て議論を重ね、また広く意見募集も行って 、「第二版」から参照されるセキュリティ基準等公表情報の一例として、Windows Active Directory環境用の文書が作成されました。

IPAはユーザ企業・ITベンダ双方が「第二版」を参照することで、契約のタイミングで双方がシステムの仕様やプロジェクト管理方法、検収方法等について、共通理解のもと対話を深め、よりよい関係のもとITシステム開発が行われることを期待しています。

見直しのポイント

  • 民法改正に直接かかわらない5つの論点

論点概要見直しの対象
見直しの観点・内容
(1) セキュリティ近年重要性を増しているセキュリティに関して、システム開発の段階においてユーザとベンダがリスクやそれに対応するためのコストについての共通理解をした上で、適切な責任分界点を設定するためのプロセス及び契約条項上の手当をモデル契約で提案できないか。条項
解説
関連文書
ユーザとベンダとは、それぞれの立場に応じて必要な情報を示しつつ、リスクやコスト等について相互に協議することにより、システムに実装する「セキュリティ仕様」を決めることが必要である。その観点から以下の見直しを行った。
  • 条項の見直し(定義条項、責任者条項、セキュリティ条項)
  • セキュリティに関するプロセスに関する解説の加筆
  • セキュリティ検討PTによる「セキュリティ仕様関連文書」の策定
(2) プロジェクトマネジメント義務及び協力義務近年特に問題となっている、ベンダのプロジェクトマネジメント義務及びユーザの協力義務について、モデル契約上の手当てによって、紛争の予防に資することはできないか。また、それぞれの義務について裁判例を踏まえて一定の整理ができないか。条項
解説
裁判例で示されたプロジェクトマネジメントや協力義務は、それぞれ個別事案における判断であり、汎用性の高いモデル契約の中にこれらの義務を規定することは難しいことから、条項の形で追記することは見送り、以下のような見直しを行った。
  • 新たな裁判例を当該事案に関連する箇所における紹介
  • ユーザ及びベンダの役割分担・プロジェクトマネジメントに関する記述の見直し
  • マルチベンダ形式における用語法の修正
  • ベンダの中止提言を踏まえた解約権のオプション条項としての追加
(3)契約における「重大な過失」の明確化従前のモデル契約においては、「重大な過失」の有無が損害賠償の責任制限条項の適用の分水嶺となっており、また、昨年12月に公表した民法改正に対応した見直しによって、ソフトウェア開発業務等の請負型の業務における契約不適合責任においても、「重大な過失」の有無が客観的起算点による期間制限の適用の分水嶺となった。この「重大な過失」について、ベンダ側の予測可能性の担保の観点からより明確化することはできないか。解説
契約条項として重過失については特段の定義をすることはせず、重過失概念に関する一般的な理解とシステム開発に関する裁判例のうち重過失についての判例を逐条解説に追記することで、重過失を考える上での手がかりを提供する。
(4)システム開発における複数契約の関係多段階契約においては、しばしば下流工程でトラブルが生じた際にユーザが上流工程まで遡って解除に基づく代金返還請求をしたり、損害賠償責任を追及するという紛争が頻発しているが、そのような紛争の予防・解決のためにモデル契約上何らかの手当ができないか。解説
複数の個別契約がどのような処理になるのかは、個別契約の関係や問題となった債務不履行次第であることから、契約条項として手当するのではなく、裁判例を整理して得られた共通理解を解除条項の逐条解説に追記し、利用者の理解に資する。
(5)再構築対応現行のモデル契約はスクラッチ型の新規開発を念頭においたものであるが、デジタルトランスフォーメーションの実行に向けた既存システムの再構築をも念頭に置いたものになるような見直しが必要ではないか。解説
要件定義に入る前に、再構築対象の現行システムについての調査を行い、その仕様を明らかにした上で再構築を行う必要があるが、現行システム調査には、専門的な技術も必要で、コストと時間を要する。現在動作している通りのシステムを再構築するだけ(現行踏襲)と考えるユーザにはこの意識が薄い。ITシステム部門向けには再構築に関するガイドブック類が公表されているものの、業務マネジメント層や契約に関わる部署に向けたものは少なく、モデル取引・契約書の中で注意喚起する。

  • セキュリティ仕様書の作成プロセス

「第二版」では、セキュリティ仕様書の作成プロセスを明確化し、その内容を解説に記載するとともに、そのプロセスを前提とする契約書の条項を整理しました。

セキュリティに関しては、公的機関や業界団体、セキュリティ関連企業等が提供する、脅威分析を行い攻撃への影響と対策(緩和策)等を検討するための参照情報(ここでは「セキュリティ基準等公表情報」と総称)を使用して、ユーザとベンダが以下のような協力をすることにより、セキュリティ仕様書を作成します。

  • 必要な情報を相互に出し合う。
  • セキュリティ基準等公表情報を参照し、セキュリティの脅威を把握する。
  • 開発対象のシステムについて考慮しつつ、脅威の影響についてリスク評価を行う。
  • 対策の実装有無を決定・合意し、その結果をセキュリティ仕様書に反映する。

対策を実装しない場合にも、その旨を記録することが重要です。そのため、システム開発の各段階において、ユーザおよびベンダのそれぞれが提供すべき情報や検討すべき事項は何か、各段階の成果物は何か、どの段階でセキュリティ仕様を確定するのか等について整理します。

このようなプロセスにおいて参照するセキュリティ基準等公表情報の一例として、今回、「情報システム開発契約のセキュリティ仕様作成のためのガイドライン ~Windows Active Directory編~」を作成しました。また、対応するプロセスについて、「セキュリティ仕様策定プロセス~「情報システム開発契約のセキュリティ仕様作成のためのガイドライン」対応~」に整理しました。

  • システム再構築における企画プロセス

長年運用・保守を続けてきたシステムを再構築する場合、現行システムに関する業務知識(ドキュメントと有識者)が失われていることが多く見られます。そのため、現行システムの状態を正しく認識した上で再構築の方針を決め、実行計画を立てることが肝要です。システム再構築におけるこのような課題と、特に企画段階のプロセスについて、「第二版」では次のような解説を追加しました。

再構築の流れとしては、まず、企画段階・システム化の方向性フェーズにおいて、再構築の目的・要求事項や現行システムの状況から最適な再構築手法を選択しリスクを洗い出します。次に、企画段階・システム化計画フェーズにおいて、選択した手法とそのリスクをもとにリスクの予防策を検討します。

ユーザは、必要に応じて、ベンダとの間で、これらの支援業務(後のシステム開発契約の範囲外)を内容とする準委任契約としてのコンサルティング契約を締結し、これらの作業のための支援を受けることになります。

このようなシステム開発プロセスにおける再構築特有の検討の位置づけは、下図の通りとなります。


  • 追補版について

今回、追補版については、時間の関係で、第一版の見直し内容がそのまま妥当する範囲で見直しを行うにとどめております。追補版については、必要に応じて セキュリティ関連のみならず、主に利用者として想定される中小企業にとってより適切なモデル取引・契約書の在り方を含め,現状の取引状況等に関する関係者の意見を踏まえた検討が期待されます。

バックアップ


さらばSolaris~2035年頃に歴史の幕を閉じるか!?~


SolarisというUNIXオペレーティングシステムがある。

20年位前までは企業のシステムの多くでSolarisが稼働しており、自分が最初に入った会社でも大量のSolarisが稼働していた。

今はOracleという阿漕な会社のものとなっているが、もともとはサン・マイクロシステムズという会社が開発し販売していた。

今はIntel製CPUがメジャーだが、Solarisは当時SPARCプロセッサで稼働しており、どうしても手元に環境が欲しくてSPARCプロセッサ搭載のデスクトップマシンを個人で持っていた時期もある。

そんでもって、Solarisのベンダー資格なんかもいくつか取得していたりした。

その後、Intel CPUで稼働するx86版Solarisがリリースされ、その辺のPCでもSolarisを入れることができるようになった。

当時Linuxはオープンソースでサポートがないことから、エンタープライズシステムには不向きとされ、Windowsはシステムそのものの安定性が全くなく(当時は1か月も連続稼働させるとフリーズする程度の酷さだった)、システムの安定性が高くてしっかりとメーカーサポートが受けられるSolarisは今後もエンタープライズシステムの中核であり続けると思っていた。

ところが、結果は想像と大きく異なり、Linuxはエンタープライズ用途に耐えられるようなサポートサービスが充実し始め、Windowsもバージョンアップのたびにシステムの可用性や堅牢性が向上し、しかもどちらも安価ときたもので、Solarisのシェアがどんどん縮小していった。

挙句の果てにオラクル社にサン・マイクロシステムズ社が買収され、雲行きがさらに怪しくなる。

実はここ5~6年くらい、Solarisに関わることがなかったのだが、先日ふとSolarisをリプレースするという案件に出くわし、久しぶりに現状を調べてみた。

そうすると、いろいろ残念な情報が出てきた。

まず、Solaris開発の大半の社員は2017年9月に解雇されているらしい。

そして、Solarisは11が最後のバージョンとなるらしい。

下記がSolarisのEOSLの表だが、Solaris11が最終バージョンとなると、EOSLは2035年となり、この辺でSolarisの歴史に幕を閉じることとなる。


自分は結構Solarisに入れあげていた半面、オラクル買収後は完全に熱が冷めるとともに、特定のプロダクトに対する熱い思い入れは持たないようにすることにしている。

IPA、国内・欧米・中国のIT関連制度政策動向レポートを公開(転載)


国内・欧米・中国のIT関連制度政策動向レポートの公開:

国内・欧米・中国のIT関連制度政策動向レポート

IPAはAI白書、情報セキュリティ白書等にて、それぞれに関係するIT関連技術の最新動向や、各国政府による研究開発の促進策、社会実装のための制度改革及び社会への実装の推進政策を紹介しています。

IT関連技術は、社会への実装という観点からは様々な分野に適用されており、関連する各国の制度政策状況についても個別分野だけでなく、全体を俯瞰した動きにも注目する必要が出てきています。各国の技術政策に関しては、大きな目標を立てた上で、個別の技術分野の制度に割り付けている例も多くみられるため、各国の技術政策を俯瞰的に把握した上で、各分野の動向の把握していくことは、それぞれの分野にとっても有用であると思われます。

そこで、IPAは、国内外のIT関連先進技術の研究開発の推進、社会実装に係る制度、政策動向の調査を行い、動向を取りまとめました。その内容を速やかに提供するため、このたび調査レポートとして公開します。