形態素解析はJanomeが楽ちん

pythonで形態素解析するのはpipでインストールできるJanomeが楽ちんである。数十万ツイート分を形態素解析したのだが量が多いとツライ。せっかくメモリーもCPUコア数も十分にあるのにシングルタスク/シングルプロセスの処理では宝の持ち腐れである。そこで並列処理をしてスループットをあげた。ついでなので大量に行単位で用意されているテキストデータをjanomeを使って並列処理で処理する時のサンプルコードを書いてみた。ちなみに自分のマシンにあわせてCPU数は16にしてある。

githubの上はこちら

#
# How to use Janome with multi-processing.
# Hironobu Suzuki 2022/Aug/24
#
import sys
from multiprocessing import Pool, Manager
from janome.tokenizer import Tokenizer

def doJanome(lineData):
	text=lineData.text
	output=""
	for token in Tokenizer().tokenize(text):
		l=str(token).split('\t')
		k=str(l[1]).split(',')
		if k[0] == '動詞' and k[1] == '自立':
			output+=k[6]+","
		if k[0] == '名詞' and k[1] == 'サ変接続':
			output+=k[6]+","

	output=output.rstrip(',')	# 最後に余計な','がついているのを削除
	lineData.set(output)	# カンマで区切られた文字列 (CSV)
	return

class dataContainer:
	def __init__(self):
		self.text=""
		self.manager=Manager().list(range(0)) 

	def add(self,text_):
		self.text += text_	# 子プロセスに送るための入れ物

	def set(self,container_):	# 親プロセスに戻すための入れ物
		self.manager.append(container_)

	def get(self):
		return self.manager[0]


CPUs=16
textData=[]
for i in range(CPUs):
	textData.append(dataContainer())

content=sys.stdin.read()        # 標準入力からすべてを読み込む。

idx=0
for line in content.splitlines():
	textData[idx%CPUs].add(line) # 行単位で分配
	idx+=1

with Pool(CPUs) as pool:
	pool.map(doJanome,textData) # 並列処理

# 一覧作成
for content in textData:
	for w in content.get().split(','):
		print(w)

NASAに学ぶ“反面教師”のセキュリティ対策

※本記事は2019年11月にNTTコミュニケーションズ運営サイト「Bizコンパス」(現在は非公開)へ寄稿した記事のオリジナルを掲載したものです。そのためサイト掲載時にはない誤字脱字などがあると思いますが、筆者であるわたしのミスですので、ご容赦ください。

NASA監査部が行ったジェット推進研究所のサーバーセキュリティ監査の報告書は公開された。今回はその報告書をベースにしてNASAからサーバーセキュリティマネージメントを学んでいきたい。

2019年6月18日づけでNASA(米国航空宇宙局)の監査部からの監査報告書が「CYBERSECURITY MANAGEMENT AND OVERSIGHT AT THE JET PROPULSION LABORATORY (https://www.oversight.gov/sites/default/files/oig-reports/IG-19-022.pdf) 」が公開された。

数々の宇宙探査研究プロジェクトを抱えるジェット推進研究所のサイバーセキュリティマネージメントに対する監査報告書だが、答えを先にいってしまえば、これが宇宙探査をしている最先端科学の現場か、とびっくりするぐらいにずさんな管理をしている。

しかし、そこに書かれているサイバーセキュリティの問題は、企業や大学などで抱えている問題であり、そのずさんな管理はよく見る風景そのものである。この監査報告書の指摘は、多くの組織で共有できる問題であり、学びになるだろうと考え、今回取り上げてみた。

NASA傘下のジェット推進研究所(JPL)とは

NASAは、いまさら説明する必要もないほど有名な米連邦政府の宇宙開発を担当する組織である。ジェット推進研究所ジェット推進研究所(以下JPL)は、NASA傘下の研究所で、主に無人探査機による研究開発および運用を担当している。中心となるキャンパスは米カリフォルニア州パサデナにあり、地理的にはなれているいくつもの研究ブランチがネットワークで接続されている。

JPLがサポートする研究プロジェクトには、火星探査プロジェクトやボイジャープロジェクトといった有名な宇宙探査プロジェクトがあり、JPLが提供するネットワークは13の研究プロジェクトに利用されている。JPLネットワークのサイバーセキュリティは、NASA監査部がJPLネットワークのサイバーセキュリティ評価をしている。

今回の報告書を読むまで、筆者は知らなかったのだが、JPLはNASAが作ったものではなく、前身はカリフォルニア工科大学グッゲンハイム航空研究所で、今も、NASAはカリフォルニア工科大学と運営委託契約してJPLを運営している。2018年にもNASAは5年・150億ドル(約1兆6,000億円)でカリフォルニア工科大学と再契約を済ませている。大学に運営管理を委託しているというバックグラウンドが報告書を読み解く上で大きなヒントになった。

NASAは常に狙われているのではあるが…

NASAは航空宇宙関連の最先端技術やこれまで集めた惑星や宇宙の膨大なデータだけではなく、国際武器取引規則(International Traffic in Arms Regulations: ITAR) にも抵触するような情報を大量に抱えている米国政府の科学技術部門のに属する組織である。

この報告書の一番はじめに「NASAは極めて魅力的なターゲットである」とNASA自身で書いている。産業スパイ、敵対国のスパイ、ネットワーク侵入を試してみたいサイバー組織やあるいは一匹狼がやってくることは想像がつくし、実際にそうなっている。筆者が思うに、政府は宇宙人の証拠を隠しているに違いないとネットワークに侵入してくる連中もいることだろう(冗談ではなく大真面目にいっている)。

一方でNASAの一部門であるJPLは、報告書を読む限り、地球や火星といったものを研究する地球惑星科学や宇宙を研究する天文学の牙城で、極めてアカデミック色が強く、さらにネットワーク運営はカリフォルニア工科大学が管理している。

そのためか、政府で国際武器取引規則が適用されるような組織であるにも関わらず、サイバーセキュリティに関する対応が、後手に回っている印象を持った。報告書には、よく日本国内の企業や大学で見聞きするような、「あまい」管理をしている状況が厳しく指摘されている。なので身近に感じる話題の部分もたくさん現れる。

JPLは地球、惑星、宇宙を対象にした研究を円滑に進められるようにパサデナ以外にいるJPLの研究者、海外の共同研究組織に所属する研究者、無人探査機やシステムを作る業者、天文学などを学ぶ学生などがJPLのシステムを使えるように外部からのアクセスを許可している。それらのユーザー管理は、もちろんJPLの管理下にあるわけだが2018年10月時点で放置されているアカウントが153アカウント、うち54アカウントはすでにJPLを退職していたという状態だった。放棄されたアカウントの中で99つをサンプル調査したところ、7年から11年が経過していた。かなりルーズである。

大学では卒業・退学者は遅滞なくアカウントを停止することになっているが(〜もちろん規則通りに滞りなく処理しているところもあるだろうが〜)いつまでもアカウントが残っているのはわりと「あるある」ネタである。研究所から大学に移動した研究者も以前のプロジェクトのアカウントを残していて放置状態というのも「あるある」ネタだ。あのNASAでもあまり変わりがないのだな、と、ある意味、納得できてしまう筆者であった。

中国への情報流出

報告書にはJPLが過去に経験した大きなインシデントがいくつか紹介されているが、興味深いのは2009年と2011年の中国がらみの件だ。

  • 2009年:インターネットから攻撃者の侵入を許し、22GBのプログラム及びデータが流出している。このデータは国際武器取引規則に抵触するものであった。流出先ホストは中国国内のIPアドレスであった。この件をうけてネットワーク型ファイアウォールのみ利用から、ホスト型ファイアウォールも加えて、マルウェアの内部感染にも備えるようにした。

  • 2011年:中国国内のIPアドレスから不正侵入を許し、JPLが管理する18台のサーバーの特権権限を盗取された。サーバーには宇宙探査プロジェクトで利用されているミッション・クリティカルなシステムも複数含まれていた。また調査した結果、発覚以前に87GBのデータが流出していたことがわかった。この件をうけて受けてネットワークやシステムで不正な活動を検知する仕組みを実装し、また情報流出などの問題を対処するための専門担当者を組織内のサイバーオペレーションセンターの人員に加えた。

2009-2011年でも、すでに多重防御によってネットワークを守るといったことや、専任スタッフの配員など少なくとも先端的な企業では、すでに当たり前になっていたが、JPLは取り入れていなかったようだ。そのむかしはネットワークの入り口にファイアウォール機材を設置しておけば、その内部ネットワークは安全であるといったモデルだった。いまもこのモデルが有効だと信じている人がいるようだが、現実には、ネットワークへの侵入方法は多種多様であり、100%侵入を防ぐということはありえない。

たとえば攻撃先サイトのユーザーにマルウェアつきのメールを送り組織内ネットワーク上にあるPCにマルウェアを感染させ、そのマルウェアがさらに内部のPCやサーバーなどに感染を広げるような場合を想定しなければならない。ネットワークのセグメントを適切に分割し、そのセグメントレベルでファイアウォールを設置し、さらにホスト自身がファイアウォール機能を稼働させる多重防御することが今では当たり前になっている。最近では「ゼロトラスト」というキーワードがあちこちで見かけるが、元々がネットワークでつながってしまえば安全な場所などなかったはずなのでネットワーク・セキュリティの当たり前のことをいっているに過ぎない。

1年近く侵入に気づかぬまま放置してしまった背景

2018年に発覚したインシデントは、侵入された後、内部ネットワーク内に活動拠点を作られ、おおよそ10ヶ月にわたり活動した。23ファイル、容量にして500MBのデータが流出したことが確認できた。そのうち2ファイルは火星探査プロジェクトの火星探査車マーズ・ローバーの情報が含まれており、これは国際武器取引規則に抵触する情報であった。

この問題が発覚して、NASAの監査室はJPLを本格的に監査する必要があったのだろうと推察できる。「執拗に繰り返し攻撃されるタイプで、この攻撃が発覚するまで1年近くかかった (Classified as an advanced persistent threat, the attack went undetected for nearly a year.)」と報告書にある。

報告書には続けて「JPL内部ネットワークへの侵入は外部利用者のアカウントを不正に利用していた。」「外部から侵入の後、組織内ネットワークに接続されているシステムの脆弱性を探索し、侵入、情報の盗取など約10ヶ月間に渡り活動していた。」「内部ネットワークに申請も許可も得ていない脆弱性を持ったままのRaspberry Piが接続されており、外部からの侵入者はこのマシンを内部での活動拠点としていた。」と記されている。かなりやられっぱなしである。

資料から察するに、JPLネットワーク内ではネットワークが適切なセグメントで管理されておらず、一旦、JPLネットワーク内部に侵入するとかなり自由度が高く、他のミッションのシステムへもアクセスもできてしまうようだ。外部からの侵入者は時間をかけてJPL組織内のシステムを探査することが可能だったので、システムの持つ脆弱性を見つけることができたのだろう。

Raspberry Piの不正利用は簡単に見抜けない

Raspberry Piが外部からの侵入者をの拠点となっていた」としていたという話は、あちらこちらのWebニュースサイトで話題になっていた。

Raspberry Piは、いまでこそ見劣りするスペックだが、ふた昔前のエンジニアリング・ワークステーションよりも性能がいい。ソフトウェア構成もLinuxサーバーと同じである。つまり、ごくごく普通のLinuxサーバーとして使える。そして当然であるが管理にはセキュリティも含めた上でのサーバー管理のノウハウが必要である。

JPLでの内規では、ネットワークに接続するいかなる機材も事前申請が必要で、さらに機器監査をうけて認証を受ける必要がある。誰かが密かにRaspberry Piをネットワークに接続し……といった陰謀があったわけではないようだ。事前申請も機器監査も約束事としてあるにはあるが、日常的に無視していたようである。

日本でもISMS認証取得の条件では情報資産管理台帳を作り、接続している機器を管理するのが建前だが、そんなに厳密にはしていないのが現場の状況だろう。管理帳簿につけ忘れたり、申請することを知らずに勝手につけたりして、誰が管理しているのかよくわからない機材がネットワークに接続されているのは、これもまた「あるある」なネタなのではないだろうか。

JPLではウェブベースのきちんとした管理システムもある。しかし報告書には「あとから登録しようとして忘れていた」「入力しようとしたらエラーになって、よくわからないのでそれっきりにした」といった現場の声が載っており、筆者も読んでいておもわず「あーあ」と声を漏らした。世の中、どこでも似たようなものなのだ。

もう一つRaspberry Piがやっかいなのは、小さくて目立たないことである。しかも無音だ。これがサーバーのように大きくガーガーと音を出して部屋に鎮座していれば、いやでもその存在に意識を払うだろう。しかしRaspberry Piがディスプレイにも接続されず机の片隅におかれて動いていたら誰も気にもとめない。これも大きな盲点である。今ではクレジットカードサイズよりもさらに小さいボードコンピュータが現れているので、そんなのが本や資料の間に挟まれてWi-Fi接続されていたら、もう目視では見つけるはむずかしい。

米国でRaspberry Piが侵入者に使われていた話は大きな話題になりあちこちのWebメディアで騒がれた。それを引用した形で日本のWebメディアでも紹介されたが、こちらは一部の専門家以外は、ほとんど注目しなかった。実はRaspberry Piを組織内のネットワークに設置し、外部から不正にアクセスしコントロールするという手法は、2015年に放映された米国の人気テレビドラマMr. ROBOT で使われており、多くの一般人も知っていたのである。そしてTVの中のフィクションが現実になったことに驚いたはずである。

同作品で主人公のエリオットを演じているのはラミ・マレック。後に映画「ボヘミアン・ラプソディ」で伝説的ロックバンド「クイーン」のボーカリスト・フレディ・マーキュリーの役を演じ、爆発的な人気を博することになる。劇中フレディーがエイズの宣告を受けた後、病院の廊下で言葉を交わすのはMr. ROBOTでタイレル役を演じていたマルティン・ヴァルストロムである。

人の振り見て我が振り直せ

JPLは、脆弱性によりセキュリティの問題が潜在的あるいは実際に発生した時に、チケットが発行されるような便利な通知システムを用意して使っている。しかし、せっかくそのようなシステムを使っていても、時として180日以上も放置されていたとある。JPLは今後30日以内に必ず処理するようなルールを定義し、責任がどこにあるかを明確にして対処した。


アプリケーションはすでにベンダーにサポートされておらずアップデートが見込めないものも長期間にわたって使い続けているというソフトウェアライフサイクルの問題がある。ただし、そこにはJPLならではの弱点があって、一度ミッションが始まれば、長い間、同じシステムが使われるという現実があるからだ。

たとえば有名な無人惑星探査機ボイジャー1・2号が打ち上げられたのは1977年である。太陽系の外惑星である木星・土星・天王星・海王星を探査し、その後に太陽系を離れ、太陽系外の探査をし続けている。プロジェクト終了は2025年頃である。そのように長期にわたって運用されることになりれば、必然的にレガシーシステムが使われ続けることになる。セキュリティ監査やシステムの入れ替えにしても、現在活動中のミッションに支障があっては困るので、慎重にならざるを得ず、時間がかかるという問題もある。

先ほどの2018年の侵入では、組織全体のネットワークが適切なセグメント化がされておらず、組織内ネットワーク境界にファイアウォールなどを設置できないという問題があった。そのため一度侵入されてしまうと、他のプロジェクトのネットワークまで侵入を広げることができた。そこでプロジェクトやミッションのレベルに応じてネットワークをセグメント化し、ファイアウォールなどを設置し多重防御をするようになった。

むかしは…今でもそうだが、インターネットと組織内ネットワークの境界にファイアウォールを設置するだけで、サイバーセキュリティ対策は終了、インターネットからの侵入は防げた、と考える人たちは多い。しかし、今どきの侵入は、まずメールあるいはメッセンジャーなどから誘導し、マルウェアをユーザーのPCに感染させる。次にそこを拠点に組織内ネットワークにある侵入者が使いやすいような機器を探し、そこに拠点を構築する。組織内部から外部にネットワーク接続をする形で、外部から侵入者が拠点に侵入し本格的な活動を始める、というような流れになっている。外側から入ることだけを、しかもシングルポイントで守っていても効果は限定的になる。

組織内ネットワークにマルウェアが入ってくるのは、もちろんメールやメッセンジャーから誘導され騙されてダウンロードしてしまったマルウェアだけではない。たとえばすでにどこかで感染しているノートパソコンを持ち込んで内部ネットワークに接続すれば同じことだ。今日ではスマートフォンやタブレッドにマルウェアが潜んでいて、組織内ネットワークに接続した次の瞬間に、他の機材に攻撃や感染を始める、なんてことも十分にありえる。どこかでの感染は避けられない。その時、組織内ネットワークは何も防御壁がなく、どこまでもアクセスできるような環境であれば、一気にマルウェアが組織内全体に広がるだろう。

対策の1つとして、利用レベルにおいて、適切なネットワークセグメントを設定し、そのネットワークの境界には防御システムを用意し、さらには自らを守るホスト型ファイアウォールも取り入れる手法がある。これらの事前の準備によって、万が一の場合も、被害を局所に押しとどめておける可能性が高くなる。

それ以外にも対策としてログの活用も必要だ。運用時に取られるJPLではログはを取得していたものの活用されしておらず、そのため侵入者が長期にわたって組織内ネットワークで活動したにもかかわらず、その予兆を見つけることができていなかった。ただし、これも本来のルールでは監査するということになっているが、ログを自動的に監査するようなツールがなければ、現実にはむずかしいだろう。一般論としても、たとえば「ログは定期的に監査する」と一言ルールに入れたとしても、それをブレークダウンして、どのようなツールを使って、どのような情報をログから抽出するかなどの手順仕様が必要である。またその情報を取り出すための具体的なツールが用意されていなければ、絵に描いた餅に終わるだろう。たとえばJPLの総システム数は3,541とあるので、数が多すぎ人海戦術では限界がある。

なお付け加えておくが、この監査報告書はJPLを対象にしているので、JPLの問題だけクローズアップしていることに注意されたい。US-CERTが2017年にNASAの依頼をうけてインシデント調査したところ、認知されたインシデント数では、NASA傘下の ゴダード・スペース・フライト・センター(243インシデント)やジョンソン・スペース・センター(278インシデント)はJPL(148インシデント)よりも多い。科学を中心にしているJPLとロケットの打ち上げなどを担当している組織ではインシデントの質が違う可能性はあるが、少なくともインシデント数に限っていえば、JPLよりも多い組織がある。

NASAから学ぶサイバーセキュリティ

 NASA監査室が公開した監査報告書からは色々なことが学びとることができる。筆者なりにまとめてみると次のようになった。

  • 定期的にレビューをおこない、現時点で上がっているサイバーセキュリティの問題について対処の進捗、あるいは抜けがないかを確認する。その時のオペレーションの責任の所在を明確にし、情報も一元管理を行う。

  • ネットワークの利用レベルに対して適切なセグメント化を行ったネットワークを構築し、おのおの各のネットワーク境界にはファイアウォールを加え、他のネットワークで問題があっても、問題を局所的に収束できるようなネットワーク構造にする。またネットワーク機器やシステムで記録されているログは異常検知に活用し、たとえ侵入されたとしても早い段階で検知できるような体制にする。

  • セキュリティの問題が発生した際のチケットを一括管理し対処する責任の所在を明確化し、また定期的に未処理のチケットが発生していないか確認を行う。チケットには最終日を決め、未処理のチケットのまま放置されるようなことがない仕組みを作る。

  • サイバーセキュリティの問題が発生した際に、どのように対処するかの標準的な手順を決めドキュメント化し、関係者で共有し、対応する人間によって処理プロセスが異なるような状況にならないようにする。

NASAを反面教師として色々なことを学べる。「このようなことは基本的なことだから、わざわざNASAから学ぶなどと大げさにいわなくてもいいのではないか」と思われるかもし知れない。いや、その逆である。あのNASAすらも、下部組織ではこのような基本的なことができておらず、このような基本を確実に行うことは誰にとってもむずかしいことである、ということを是非ともおわかりいただきたい。またこれらの問題を最近流行りの「ゼロトラスト」というキーワードで安易に括ってしまわないように願いたい。なぜならばこれらの対応は「本来すべきセキュリティ」なのであってゼロトラストという特別な枠組みではないのである。

このNASAの報告書”CYBERSECURITY MANAGEMENT AND OVERSIGHT AT THE JET PROPULSION LABORATORY”は、トータルで43ページだが、多くの示唆と学べることがたくさん書かれている。興味があれば是非目を通してみて欲しい。

(了)

Google Chrome 95.0.4638.54 アップデートしたらWebサーバが表示されない

Google Chrome バージョン: 95.0.4638.54(Official Build) (64 ビット)にアップデートしたら、いくつかのWebサーバの参照ができなくなった。ブラウザーには次のようにエラーメッセージが現れる。

ERR_NAME_NOT_RESOLVED

ERR_NAME_NOT_RESOLVED

Google Chrome以外のすべてのアプリケーションは正常にネットワークは動作しているので、システム的には問題がない。つまりGoogle Chromeだけ固有の問題である。そして ERR_NAME_NOT_RESOLVED は DNS 周りの問題である。

こっから先は、まったく手探り。システムのDNS周りも含め何やってもダメ。

そこでwiresharkを使いDNSのクエリをチェックしてみた。するとpublic.dns.iij.jpにリクエストを送りつけている。これはDOH (DNS-over-HTTPS)のサイトである。しかも、他のサイトをChromeからアクセスしているのにDNSのクエリがまったく発行されていない。これだ。「設定」「プライバシーとセキュリティ」「セキュリティ」を選ぶと「セキュアDNSを使用する」が現れ、そこには「IIJ(Public DNS)」が選択されていた。

IIJ Public DNS

これをGoogleに変更すると一発で解決した。

Google Public DNS

解決したのはいいが、本当のトラブルはどこにあるかが問題である。そういえば…むかし日本の公官庁のサイトをアクセスするとIPv6のアドレスが帰ってきてアクセスできないのを思い出した。DNSがらみで、かつ、他のサイトは問題ないのに、日本の公官庁の一部のサイトだけアクセスできないというのが、今回の一部のサイトは問題なくアクセスできる、という症状に似ている。

長年の経験と勘からDOHのサーバーをIIJにしてシステムのIPv6をオフにしたら…動いた。一々IPv6をオンにしたり、オフにしたりするのは面倒なのでDOHサーバをGoogleにした。

実は家にあるNTT東日本の光ルータが古くてIPv6を通過させることができない環境なのである。取り替えればいいのだが、レンタル品なので、手続きが面倒でそのまま。困ることはなかったし(少なくとも今日までは)。自分以外でも問題がありそうなものだが、世の中の大半の人はIPv6で問題ないのだろうか。それともシステムレベルでIPv6をオフにしているのだろうか。

というわけで、もし、Google Chrome バージョン 95.0.4638.54 にあがってDNSエラーのようなメッセージが出て接続できない場合は、DNS-over-HTTPSの設定を疑ってみると良いだろう。