セキュリティー と プライバシー

1•https://cybermap.kaspersky.com/•https://threatmap.fortiguard.com/•https://threatmap.bitdefender.com/•https://threatbutt.com/map/

2

3

4

5

6

7

8

9

10

11

本当の 攻撃者は誰?
• 組織内部 ： 大半
• 社員は信用できない。 ➔ ゼロ トラスト

• 組織外部 ： 少数
• 保守的人種 (組織の内外を問わず)• 新しいもの(e.g.,技術)には危険/リスクはつきもの。。。。。でも、現状を維持したがる。

12まず、、、、、
サイバーセキュリティー
✓完全(＝安全）は、存在しない。
✓暗号化技術は、超難しい数学を使うけど、結局は、「いいかげん」 (＝安心）13セキュリティー の 「大枠」
◼ 何が問題なのだろう?
➢ 「個人情報保護法」、「青少年ネット規制法」➢ 「組織犯罪処罰法」 (＝「共謀罪法」、「テロ等準備罪法」◼ 「(情報)セキュリティー」はどうあるべきか?
➢ 安心してのびのび仕事ができるような環境(*) 事故が起こらないように 委縮した活動環境?
(*) 実は、職場の 「安全衛生管理」と同じ。
➢ 「放蕩」 と 「箱入り」、どっちが強い?

➔ 意図的な“Diversity”環境の構築
14➔ 公助&Firewallの罠本当の 攻撃者は誰?
【注意が 必要な 常套手段】• 組織内部 ： 大半
• 社員は信用できない。
◆ たくさんの攻撃 に 遭遇 しています。
1. 攻撃者 を 発見 したいですよね。
• 組織外部：あけますよ。
少数
2. 攻撃から守って
3. 僕を信頼して 中身を 見せれば安心ですよ。

• 保守的人種 (組織の内外を問わず)◆ 「繋いでいない」から大丈夫です。
• 新しいもの(e.g.,技術)には危険/リスクはつきも
1. だから、セキュリティー対策は不要 です。
の。。。。。でも、現状を維持したがる。
2. でも、繋がるかもしれませんよね。。。
3. システムをアップデートすると 保証 できなくなってしまいますよ。
(脅し、恫喝)15

How do you think?
『項羽と劉邦』 (司馬遼太郎著)より。。。。やがて華何が死に、曹参は後任を命ぜられた。 彼は、斉の丞相の職を後任に譲るとき、「それでは、斉の獄市を貴官にお渡しします」と言った。 獄市とは商品の市場のことである。むろん、この時代といえども政治は多岐にわたっており、獄市のみではない。 後任者は不審に思い、政治にはほかにもっと大事なものがあるのではないでしょうか？ と反問すると、「獄 と 市だけが、政治の要です」と、曹参は言った。 曹参の考えは、牢獄も商業の場も、善悪ともに 受け容れるところです、これに対して為政者が善悪に厳格でありすぎると、かえって ぐあいが悪くなります、ということであった。
・・・ (略) ・・・・
曹参は、世の中には必ず姦人とい者がいる、という。 これをやわらかくつつむのが、曹参の社会に対する生理学的な認識のようであった。 そういう姦人たちは、司法の対象になるか、市場管理の対象になるかどちらかだが、この獄と市をあまり やかましく正しすぎると姦人は世に容れなくなり、必ず乱をおこし、国家そのものを毀損することになる、だから獄市は大切だと言ったのです、曹参は答えたと いう。

著作権・知的財産権の規制もしかり
<個人>

<個人>

発明

<公的場所>

思考
思考

過度な規制
<個人>

発明
公開 & 利用<個人>

発明<公的場所>

思考

発明

思考
発明

思考

公開 & 利用

<個人>

<個人>

発明

<個人>

発明

<公的場所>

思考

思考
<個人>

発明

交流の
促進

思考

公開 &
利用

発明
思考
17

<個人>

“セキュリティーの(正しい)意義【誤】： ① 風紀委員の増強② 安全(“ゼロ”)の実現【正】: 1. “安心”(not 安全)の実現
2. “のびのびと”仕事
3. リスク対応(“non”-ゼロ)つまり「自分で守る」が基本&前提“セキュリティーの(正しい)意義【誤】：

ゼロ・トラスト① 風紀委員の増強(Zero Trust)② 安全(“ゼロ”)の実現【正】: 1. “安心”(not 安全)の実現
2. “のびのびと”仕事
3. リスク対応(“non”-ゼロ)暗号化・認証アルゴリズム[1] 平文の認証 (一般には、 N bits(入力) → m bits(出力), N>m)[2] 平文の暗号化① DES(Data Encryption Standard) ; 秘密鍵方式② RSA(Rivest, Shamir, Adleman) ; 公開鍵方式

20

さて、暗号化は何をしているのか。
• {平文}文字の空間 と {暗号}文字の空間 との間の 写像{F(文字,パラメータ)} の計算を行っている。 {暗号}文を、たくさん 眺めると, 文字 と パラメータ が 見えてくる。
• この {たくさん} が、十分に大きければ よし とする。
• {暗号}文の空間 も、写像関数F もほぼ、無限に存在する。
• 写像関数 F の 逆関数 F-1 が存在すること• 必ず、1対1 の写像となっていること。
(*) 認証では、この条件が少し甘くできる。
21

平文の シンボル(e.g., 文字)集合(X)

暗号文の シンボル(e.g., 文字)集合(Y)y2=f(x2, Key)x1

y3=f(x3, Key)x2

y1=f(x1, Key)x3

y4=f(x4, Key)x4

y = f (x, Key)x = f -1(y, Key)(*) 必ず、(i) f -1 が存在(ii) 写像は、1対1
y1 ≠ y2 for any x1, x2(*) Key は、ユーザごとに定義

平文の シンボル(e.g., 文字)集合(X)

暗号文の シンボル(e.g., 文字)集合(Y)y2=f(x2, Key)x1

y1=f(x1, Key)x2

x3

y4=f(x4, Key)x4

y = f (x, Key)(*) もし、同じ y に写像される x が複数存在すると f -1 が存在しないことになり、暗号の 複合 ができなくなる平文の シンボル(e.g., 文字)集合(X)

x1

x1

x2
x3
x2
x3

暗号文の シンボル(e.g., 文字)集合(Y)y = f (x, Key1)

y = f (x, Key2)

y1
y2
y3
y4
y5
y6

(*) 同じ写像関数(暗号化関数) f を用いていても、関数 f のパラメータである Key が異なれば、写像値(暗号文のシンボル)も異なる。

平文の シンボル(e.g., 文字)集合(X)

x1

x1

x2
x3
x2
x3

暗号文の シンボル(e.g., 文字)集合(Y)y = f (x, Key1)

y = g (x, Key1)

y1
y2
y3
y4
y5
y6

(*) 仮に、暗号化に必要な 鍵 (key) が同じでも、異なる写像関数(暗号化関数) を用いることも可能。

26

公開鍵暗号方式

例； ssh (Secured Shelll)
出典: http://www.psn.or.jp/TROUBLE/security.html

27

電子署名方式

・ MD5 (128 bits)
・ SHA (160 bits)

出典: http://www.psn.or.jp/TROUBLE/security.html

28

PGP暗号化メール

公開鍵暗号化方式(暗号化方式； RSA+IDEA)
出典: http://www.psn.or.jp/TROUBLE/security.html

29

鍵の証明と配布
・証明を発行する機関・組織を利用
例； Netscape Webサーバ 暗号化情報交換

出典: http://www.psn.or.jp/TROUBLE/security.html

30

資料提供：
代表取締役社長 木村 幹夫 氏

インターネットの裏方
公開鍵方式

31

私達が仕事でネットを使えるのは重要なデータのやりとりができるから

32

重要な文書を安心して注1送れるのは他人にのぞき見られたり改ざんされたりしないから

注1：安全ではないが安心
33

暗号化技術がインターネットを支えている34

どんなハイテクが使われているだろう？

35

その前にちょいと歴史を36

人類は古代～１９７０年代まで
暗号のときは一種類の鍵でやりくりしていた37

「暗号化が大変なら複合化も同じくらい大変だよね！」
という発想

38

できるだけ難しい暗号化を考えよう

39

でも暗号の鍵と復号の鍵は同じ

40どんなに難しい暗号の仕組みを作っても・・

41

それって
1.送受信の間に鍵を盗まれたらアウトだよね
2. たくさん通信したら鍵がばれやすくなる 注2

注2: 鍵を毎回変えればいい。 毎回違う新しい鍵(Key-2)を鍵(Key-1)で知らせれば、はるかに ばれにくくなる。
42

暗号以前に鍵をどうやって安全に受け渡しするか？
の根本問題があった43

何とかならないのか？

44

鍵を分けたら良いんじゃないか？

45

「暗号化だけ」できる鍵＆「複合化だけ」できる鍵

46

書類を送ってもらう相手に「この鍵で暗号化してね」とメッセージする

47

暗号化した文書が送られてくる48

解読できるのは複合化の鍵が分かっている自分だけ49

復号の鍵は送らないので、文書と暗号鍵が盗まれても、解読されない

50

なかなかCOOL！

51

でも、暗号化の鍵から複合化の鍵が類推できるなら意味がないよね？

52

暗号化できる鍵を知っていても複合化できる鍵が作れなかったら良いはず53

そんな都合の良い話があるのか？

54

実はあった！

55

これは何と何のかけ算でしょう？
6590345592383228560957359299581839000109274906104197502334821653357761099517613
0640367526195179841942093509410963954149527509952291913377016848693318906814699
0122638578681299724765786565109905538811117702587975850622614126727499487983786
8424239970217566952950257966494786676764041481039876268589414733563617885862361
3567219655261002060926595514905342663211450670589508347104787010186858355630781
4843666327903699778617915563355578695800173273721038751403858104606550440301478
4557256100681843648960037204536264127830774896762175764971679360712793450552148
3562660305502309963888076930350701402560888611858728164813483701643481692838758
4508117909444519620291361953315564941839065903698573664980615465313228356506045
2266286908442896164094049020471538703575709266088863053691017574199707534530654
9007526718619001571394956902313412019506955622442191884025175204713747664248828
9261842750842716747427383529023842769107104409539201621874543017935433181379867
1687527037126831417703105249943076673569883270044237323861999717774133942214637
2097780799880252336672361560928266614342791343409307837811759903975484364591607
14644362819550161556873953

56

注3： RSA暗号
こたえ注3
素数p
3139913993711991311397993319113771475298959419915878794563614167933437977542898
5257551713331268426994369597894664451686364896153698135497737593567341879528736
9494189373478623641239162919379269294319941871985794933399739235523691657154837
8891178342326789744496582791171295228954882226124497164356511127978681187224751
1236731871835995433275685115284567355434383342395832412927924257154395624431215
9149656971499164148747227159798119915531789396889314926554998567389189177184378
4113568875799667325193957696344849464841557368591957739764855875988117131969227
7264831974241325966579811156631484595455134432129279217858321815571114361173549
9324729469232679643212644511755544726594454683193623626957711324895114496128478
8963751575976599742464673159369115317922882392491364943297888457288316117288576
3934333744949322156173895933914134711913833265321911961298416366931735662463195
2956188127648784846583361813646131913157456632928169513747231224138425962243343
3711454877459544125874848379332386422788519551485745125951999696856122454391187
37626399742196143742577819117917319979999777371311371999793393と素数q20988936657440586486151264256610222593863921
57この組み合わせを見つけるのは計算機を使っても大変！
何年もかかる58

桁数を増やせば、1000年でも解けない問題を作るのは簡単だよね59

元ネタの２つ（pとq）を知っていれば、かけ算（p*q）は一瞬でも結果(p*q)から元ネタ(pとq)の推定は
膨大な時間を削られる

60

かけ算の結果 ＝ 暗号鍵

元ネタ ＝ 復号鍵になっていれば良い

61

かけ算の結果 ＝ 暗号鍵～（公開鍵）
元ネタ ＝ 復号鍵～（秘密鍵）62任意の素数を２つピックアップすれば良いので鍵は即座にいくらでも作れる素数は無限にある63

その鍵を解くのは膨大な時間がかかる計算機を使っても追いつかないだから公開鍵方式は安全注4
注4: 正確には安心。計算機の能力(e.g.,量子コンピューティング)が向上すると暗号が解読される確率が大きくなる。
64

プライバシー65

“Privacy by Design” (PbD)
7つの原則
1. リアクティブ(事後)でなくプロアクティブ(事前)2. ディフォルト設定でプライバシー保護
3. 設定時に組み込むプライバシー対策
4. ゼロサム ではなく ポジティブサム
5. エンド・ツー・エンド でのセキュリティー
6. 可視化と透明性 (オープン性・公開性)7. 個人のプライバシー尊重(個人を主体に)

66

プライバシー• (他人からの干渉を受けない個人の)私生活• 秘密, 内密
• 隠遁(いんとん)• Private の名詞形

かなり、主観的な面が強い。。。。。
➔ 結局は、セクハラと 類似している

67

プライバシー• 結局は、セクハラ、アカハラ、ドクハラ と似ている。
• 同じ事象でも、問題がない場合と、問題になる場合とがある。
• 基準も時間とともに 変化していく• 必ず 騒ぎ出す ひとがいる。
• 最初から話をするべし！
68プライバシー• 対策は、責任の所在を明らかにすること• 基本的には、個人で守るしかない。
• しかし、個人情報に 合った サービスを 顧客はありがたがる。
➔ 情報の 2次流通、2次利用に関するコンセンサスの必要性

69

プライバシー• 結局は、誰が(Who)、 何の目的で(Why)、どのよ
うに(How & Where)、いつ(When) 個人の情報を利用するか。
➔ なんだ、5W 1H じゃん。

• デジタルもアナログも基本的には同じ。 デジタ
ルは、情報の流通速度を大きくする。

70

プライバシー• ところが、、、、、• 情報理論：秘密の情報(＝貴重な情報) ほど、高い価値がある。

• プライバシー
公然の事実（＝普通の情報）になると、プライバ
シーではなくなる71

プライバシー•デジタル技術の効果
• 複製
• 流通
• 共有
• 加工

攻撃側が
とっっても有利になちゃったぁ。

が 簡単に できちゃう !!!
72

ところで、通信の秘匿性• 何のために、秘匿性が必要なのだろう ?
• 「匿名性」 は 何の ために必要なのだろう ?

• なぜ、「ブロッキング」 は、大きな 議論の対象になるのだろう ?

73

セキュリティー74

セキュリティーと辞書で引くと• 安全, 無事• public ～ 治安, 公安/in ～ 安全に, 無事に.

安心 と 安全は 同じ なの？

• 安心, 心丈夫
• (財政上の)安定, 保障:⇒social security.
• 〔危険・危害などに対する〕防衛(手段), 警備(態勢), 安全保障
〔against, for〕
• (負債の支払いに対する)保証, 担保, 抵当(物件)、保証人、有価証
券:government securities 政府発行の有価証券(e.g., 国債・公債)
75

安心• 個人の主観的な判断に大きく依存するものである。当懇談会では安心について、人が知識・経験を通じて予測している状況と大きく異なる状況にならないと信じていること、自分が予想していないことは起きないと信じ何かあったとしても受容できると信じていること、といった見方が挙げられた。 人々の安心を得るための前提として、安全の確保に関わる組織と人々の間に信頼を醸成することが必要である。互いの信頼がなければ、安全を確保し、さらにそのことをいくら伝えたとしても相手が安心することは困難だからである。よって、安心とは、安全・安心に関係する者の間で、社会的に合意されるレベルの安全を確保しつつ、信頼が築かれる状態である。完全に安心した状態は逆に油断を招き、いざというときの危険性が高いと考えられる。よって、人々が完全に安心する状態ではなく、安全についてよく理解し、いざというときの心構えを忘れず、それが保たれている
状態こそ、安心が実現しているといえる。
2004年4月 文部科学省「安全・安心な社会の構築に資する科学技術政策に関する懇談会」の報告書

76

安全• 人とその共同体への損傷、ならびに人、組織、公共の所有物に損害がないと「客観的に」判断されることである。 ここでいう所有物には、無形のものも含む。世の中で起こりうる全ての出来事を人間が想定することは不可能であり、安全が想定外の出来事により脅かされる可能性は常に残されている。そこで、リスクを社会が受容可能なレベルまで極小化している状態を安全であるとする。同時に、社会とのコミュニケーションを継続的に行う努力をすることにより、情勢に応じて変動しうる社会のリスク受容レベルに対応する必要がある。 安全を高めようとすればするほど、利便性や経済的利益、個人の行動の自由等が制約され、プライバシーが損なわれる可能性がある。よって、安全性を向上させる際には、このようなトレードオフの関係を考慮する必要がある。しかしながら、より高いレベルの安全を実現するためには、安全と自由のトレードオフの次元にとどまらず、
安全性と行動の自由やプライバシーを並立させる努力を続けることが重要となってくる。
2004年4月 文部科学省「安全・安心な社会の構築に資する科学技術政策に関する懇談会」の報告書

77

セキュリティー• 経済面での観察
1. (とても) お金がかかる
さらに、、、、完全性が保証できない。。。。

2. お金を払いたがらない
事故が起こらないと必要性を認識しない。
➔ 適度な事故が発生しないとお金を払わない。
⚫

ということで、セキュリティーのビジネスが成立する社会＝ “適度に” 事故がある
78

セキュリティー• 必要なこと / 実現すべきこと
守るべき物に関して、以下の2つを実現。
1. 破壊・変更(改竄)されない
再生コストを必要とする事故

2. 盗難されない & 不正利用されない
a. 再生コストを必要する 事故
b. 他人のコスト負担を必要とする事故
79

セキュリティー•

可能な対策
1. (修復)コストを保障/補償 (保険, insurance)
2. 事故を未然に防ぐ (Pro-active)
3. 事故発生時の対応策
a. 事前策 (Pro-active)b. 事後策 (Re-active)•

注意すべき点1. 完全性は要求不可能(*) 事前、事後の両面において

2. “完全な” 社会ではセキュリティービジネス自体が成立しない
80

セキュリティーさらに、「法律で規制」に。
By 効果があることを証明(導入で事故が減少する)• 例えば、デブ への生命保険• 困ること• 死亡 ➔ 収入の喪失• 疾病発生➔治療費(*) つまりは、収入の減少• 保障すべき物• お金• 最近保険会社がやっていること

昔の先例：
火災報知器 と スプリンクラー 消火器with 火災保険
最近の例：
自動車 衝突回避機能、次に 運転記録
with 損害保険• デブにならないようにする方法を奨める  ここに AI と IoTi.e., 予防策の伝授 ➔ 保険利用の確率を下げる。
81

いろいろなモデルがある。。。。
• オープンソース至上主義• すべての ソフトウェアは、オープンソースでなければならない。
• ブラックボックス VS オープンソース(Microsoft)(Linux)• ブラックボックスがないとセキュリティーは実現不可能• ブラックボックスだと、手が出せない• オープンソースは、誰でも設計図を持ってしまう。
82

ところで、対策コストはどうなる ?
• 手段の共通化共有化が容易• 陽： 守りの強さを常時同レベルに維持可能• 陰： 攻めるための情報• 鍵&方法 の複製コストが低下• 陽： いつでも、鍵&方法は変えられる• 陰： 鍵&方法は すぐに 複製され流通可能
83

プライバシー vs セキュリティーの事例• 尖閣諸島中国漁船衝突映像の流出事件 ： 2010年11月4日
1. 海上保安庁 石垣海上保安部 が録画
2. 沖縄地方検察庁が映像ファイルを保管。
3. 神戸市内所属の海上保安官が、映像ファイルをダウンロード、インターネッ
トカフェから本画像ファイルYouTube に をアップロード。

• 問題点• サイバーセキュリティ対策
1.
2.
3.
4.

不十分な 海上保安庁、検察庁の サイバーセキュリティ対策  安全な環境との認識？
当該 保安官 の 逮捕を 見送る。
保安官を配置換え、2010年12月に 「退職願」を提出。
「退職願」は一旦拒否されたが、その後 「受理される」
 甘すぎる処分• プライバシー確保
1. 新聞記者は、取材先の 秘匿性を守っていた。  表現の自由の確保のための原則
2. ISP/CSP が、｛令状なしに｝アクセスログ情報を提供した。。。。 通信の秘匿性
84

具体的な 対策85

ネットワークセキュリティー
実世界の “価値ある” 情報がネットワーク上に存在し交換流通されている。
→ 情報の保護、利用者の認証、不正アクセスの防止サービスの継続
保護対象；(1) データ(a) 機密性(他人に知られたくない情報)
・・・・ C : Confidentiality(b) 保全性(他人に変更されたくない情報) ・・・・ I ： Integrity(c) 可用性(管理を必要とする情報)・・・・・ A ： Availability(2) 資源 (CPU、メモリなど)(3) 評判(4) サービス
86

87

DDoS (Distributed Denial of Service) 攻撃の仕組み
Attacker

MasterDeamonAttackWebサイト
88

89

90

91

ネットワークセキュリティー
1. セキュリティーポリシーを決める
2. ユーザーの認証(パスワード管理)
3. ファイルの保護
4. Secureなホストへの アクセスの方法
5. アクセス制御(xinetd， TCP wrappers)
6. 暗号化 (IPsec)
7. Firewall (e.g., socks)
8. 電子メールシステム

92

ユーザの認証(アカウント管理)
1. 想像しにくいパスワードの使用-すべて小文字、すべて大文字とか、、、、

2. パスワードファイル(/etc/passwd)の保護- Shadow Password File ； /etc/master.passwd
3. 使い捨てパスワード(OTP； One Time Password)- Challenge & Response 型 with 共有鍵
4. ssh ； Secure Shell- 暗号化された Remote Login with 公開鍵+秘密鍵
5. RADIUS (Remote Authentication Dial In User Services)- ダイアルアップユーザに対する認証処理
6．2段階認証 (信頼できるアンカーポイントの存在を前提に)
93

使い捨てパスワード ； OTP
・毎回異なるパスワードを利用する。
・Challenge & Response 型の認証
・同一の鍵をサーバーとクライアント間で共有する。
・例えば、
ftp://ftp.nrl.navy.mil/pub/security/opie/opie-2.3.tar.gz

・Windowsのクライアントソフトもある。
19462
19462

28472

f(19462,28472)= JOB ARTS WERE FEAT TITLEJOB ARTS WERE FEAT TITLE
OK
94

安全なRemote Shell- ssh ； secure shell ・公開鍵暗号方式； 公開鍵＋秘密鍵
・フィンランド ヘルシンキ大学で開発・RSA、 IDEA、 DES 方式による暗号化
・例えば； http://www.cs.hut.fi/ssh
・Windows版クライアントもあります(Teraterm)
・sshd (secure shell daemon)・ssh (rlogin)、scp (rcp)、ssh-keygen
・鍵情報ファイル
.ssh/identity.ssh/identity.pub (client) => .ssh/authorized_keys (server).ssh/ssh_known_hosts, /etc/ssh_known_hosts95安全なRemote Shell- ssh ； secure shell 1. 公開鍵(Public key)の交換とチェック/etc/ssh_known_hosts、 ..ssh/known_hosts
2. クライアントは秘密鍵を使って Session Keyを送る(*) Session keyは毎回変わる。
3. サーバは公開鍵を使って Session Key を平文化する
4. Session Keyを用いて暗号化・平文化
公開鍵Aセッション鍵with 公開鍵A

サーバー

秘密鍵B 公開鍵A

公開鍵A
f (セッション鍵，秘密鍵B)
セッション鍵での暗号通信

クライアント96

RADIUSの動作(広域システムでの認証方式)

Dial-Up User

NAS Port Master(RADIUS Client)

Security
SystemRADIUS
ServerDial-up接続
認証要求

ユーザ確認要求

認証確認

ユーザ確認応答

User名/Passwd

認証確認

通常通信
97

ネットワークセキュリティー
1. セキュリティーポリシーを決める
2. ユーザーの認証(パスワード管理)→ 3. ファイルの保護(i) ファイルアクセス(ii) Freeソフトのインストール
4. Secureなホストへの アクセスの方法
5. アクセス制御(xinetd TCP wrappers)
6. 暗号化 (IPsec)
7. Firewall98ファイルアクセス権
３つのレベルのファイルアクセス権(1) Global，Group(SGID)，User(SUID)(2) Readable， Writable・ ｒｏｏｔ でのアクセスを極力防止する。
例;
ユーザ hiroshi の .login が Group (elab) でwritable。
/etcが Group Ownerにとってwritable (root&sysem)→ elab グループの誰かにloginされると、hiroshi の.lｏｇｉｎに次のコマンドを潜り込ませることが可能。
rm -f /etc/passwd
cp /tmp/data526 /etc/passwd
99

フリーソフトウェアの導入
フリーソフトの導入を行うときには、次のようなポイントに注意してインストール作業を行う方が良い。
(1) 特権ユーザ(e.g., root)としてはテストを行わない。
(2) ソースコードをコンパイルして使用する。
＝ バイナリコードは使用しない。
(3) Archiveをunpackするときは、内容を確かめてから（tar tf file）（4）テンポラリーなディレクトリーでの unpack（5）file コマンドでファイルの内容のチェック（バイナリファイルは注意）（6）ソースコードを眺める

100

フリーソフトウェアの導入（7） ｍａｋｅファイルを眺める。 ｍａｋｅ －ｎ
変なディレクトリーをアクセスしていないか（8） ｓｔｒｉｎｇ コマンドでＯｂｊｅｃｔファイルをチェック（9） 可能な限りｌｏｃａｌファイルでテストする（10） ｍａｋｅ －ｎ ｉｎｓｔａｌｌ でｍａｋｅプロセスをチェック（11） ＳＵＩＤ、ＳＧＩＤコマンドがあったら、要注意

101

ネットワークセキュリティー
1. セキュリティーポリシーを決める
2. ユーザーの認証(パスワード管理)
3. ファイルの保護→ 4. Secureなホストへの アクセスの方法
・ Secure Shell ； ssh
5. アクセス制御(xinetd， TCP wrappers)
6. 暗号化 (IPsec)
7. Firewall102ネットワークセキュリティー
1. セキュリティーポリシーを決める
2. ユーザーの認証(パスワード管理)
3. ファイルの保護
4. Secureなホストへの アクセスの方法→ 5. アクセス制御(xinetd， TCP wrappers)(i) 不要なサービスをシャットダウン(ii) ログをとるプログラム(ｔｃｐｄ)(iii) ホスト・サービスのアクセス制御
6. 暗号化 (IPsec)
7. Firewall
103アクセス制御
1．必要なサービスのみにしてしまう。
＝ 不要なサービスはシャットダウンする。
＝＞ /ｅｔｃ/ｉｎｅｔｄ．ｃｏｎｆ の不要な行をコメントアウト（1） 共通; ｃｏｎｍｓａｔ， ｆｉｎｇｅｒ， ｎｔａｌｋ，（2） クライアント; ｐｏｐ， ｉｍａｐ（3）ｓｓｈ導入時; ｌｏｇｉｎ， ｅｘｅｃ， ｓｈｅｌｌ， ｆｔｐ

104アクセス制御
2． tcp_wrapper
http://csrc/nist.gov/tools/tools.htm(1) /etc/inetd.conf
Before;#service socket protocol wait?
ftp
stream tcp
nowaittelnetstream tcp
nowaitshell
stream tcp
nowaitlogin
stream tcp
nowaitUser program
root /usr/sbin/ftpd
root /usr/sbin/telnetd
root /usr/sbin/rshd
root /usr/sbin/logind

arguments
ftpd
telnetdrshd
logindAfter;#service socket protocol wait?
ftp
stream tcp
nowaittelnetstream tcp
nowaitshell
stream tcp
nowaitlogin
stream tcp
nowaitUser program
root /usr/sbin/tcps
root /usr/sbin/tcpd
root /usr/sbin/tcpd
root /usr/sbin/tcpdd

arguments
ftpd
telnetdrshd
logind(2) ｉｎｅｔｄ のreread＃ ｋｉｌｌ -ＨＵＰ pid-of-inetd-process105アクセス制御
3. ホスト・サービスのアクセス制御(1) /etc/hosts.allow
fingerd: ophelia hamlet laertes
rshd,rlogind: LOCAL EXCEPT hamlet
telnetd,ftpd: LOCAL, .expcons.com, 192.1.4(2) /etc/host.deny
ｔｆｔｐｄ ： ALL ： (/usr/sbin/safe_finger -l @%h |/usr/sbin/mail -s %d-%h root) &ALL : ALL106

アクセス制御
1. セキュリティーポリシーを決める
2. ユーザーの認証(パスワード管理)
3. ファイルの保護
4. Secureなホストへの アクセスの方法
5. アクセス制御(xinetd，TCP wrappers)→ 6. 暗号化 (IPsec)(1) 暗号メール(2) トランスポート層での暗号化(3) IPsec
7. Firewall
107暗号化・ＩＰｓｅｃ
1.暗号メール- PEM, MOSS
- S/MIME- PGP (Pretty Good Privacy)
2. トランスポート層での暗号化- SOCKS (http://www.socks.nec.com/)
3. IPsec- 認証ヘッダ(AH: Authentication Header)- 暗号ペイロード(Encapsulating Security Payload)- 鍵交換プロトコル(Internet Key Exchange)
108暗号化・ＩＰｓｅｃ- トランスポートモード -Internet

IP

PayloadIP

Payload

IP

ESP

IP

ESP

109

暗号化・ＩＰｓｅｃ- トンネルポートモード -Internet

IPsec-GW
IP1

IPsec-GW

PayloadIP2 IP1

IP1ESP

IP2 IP1

Payload

ESP

110

暗号化・認証アルゴリズム(既述)[1] 平文の認証 (一般には、 N bits(入力) → m bits(出力), N>m)[2] 平文の暗号化① DES(Data Encryption Standard) ; 秘密鍵方式② RSA(Rivest, Shamir, Adleman) ; 公開鍵方式

111

ネットワークセキュリティー
1. セキュリティーポリシーを決める
2. ユーザーの認証(パスワード管理)
3. ファイルの保護
4. Secureなホストへの アクセスの方法
・ Secure Shell ； ssh
5. アクセス制御(xinetd， TCP wrappers)
6. 暗号化 (IPsec)→ 7. Firewall112

4 Levels of Firewall Configurations
Internet

Intranet(1) Simple gateway
Choke
Internet

Intranet

Proxyサーバ

Proxyサーバ(2) Belt and Suspender113

4 Levels of Firewall Configurations
Internet

Intranet

Proxyサーバ(3) TIPなどによる接続
Internet

Intranet(4) Disconnect114

ファイアウォール
1. 経路情報の交換を停止→ FW内の経路情報は外部に広告されない。
(注) Source routingで進入可能

2. パケットフィルタリング
socket{src_IP, src_port, dsrt_IP, dst_port}の情報でフィルタリングを行う。
(注) - ftpなど相性がよくないアプリケーションが存在(a) 公開されるべきサービス
WWW, anonymous-ftp, IRC(b) 公開されるべきではないサービス
NIS, NFS, PRC, TFTP, SNMP(c) 内向きを禁止すべきサービス
SMTP, NNTP, HTTP, FTP
115

ファイアウォール
3. アプリケーション ゲートウェイ ; Proxyサーバ→ 各アプリケーションでProxyサービスを提供する。
e.g., SOCKS
ftp://ftp.nec.com/pub/security/socks.cstc/socks.cstc.4.2.tar.gz

116

www.B.com

外部DNS

SOCKS

www.B.com : A2.1.1.3

外部DNS
Internet

SOCKS
Router

mail.A.com : A1.1.1.3
www.A.com : A1.1.1.4
ftp.A.com : A1.1.1.5

A1.1.1.1
Application
Gatewaysocks.A.com
A1.1.1.2
Mail.A.com www.A.com
A1.1.1.4
A1.1.1.3

内部DNS

ftp.A.com
A1.1.1.5

Intranetsocks.A.com : A1.1.1.2
117

Firewall System Configuration
Internet

External
Router外とのProxy
Proxyサーバ
内とのProxy

内→外(直接)フィルタリング

Proxyサーバ
パケットフィルタリング
特定のホスト間のみ
パケット交換を許容
Intranet
118

でも、、、、• Firewall で、システムは 守れるのだろうか?

ゼロ トラスト ネットワーキングへ
クラウド技術 ＋ 携帯網技術

119

最後に

120

そもそも、、、、、
サイバーセキュリティー
✓完全(＝安全）は、存在しない。
✓暗号化技術は、超難しい数学を使うけど、結局は、「いいかげん」 (＝安心）121セキュリティに対する考え方
1.
2.
3.
4.
5.
6.
7.
8.
9.
10.

グローバルに考え、ローカルな施策を行う「原理主義」ではなく「実践主義」で進める
強制する・制限するのではなく、活動の活力向上を応援する「過保護」は、かえってリスクを増大させる「やらされる」ではなく、「やりたくなる」を目指す
セキュリティ対策を、品質向上のための投資と捉える
経験と知見の「共有」を行う
インシデントの経験者は、「被害者」として「保護・支援」する「匿名性」の堅持 と プライバシーの保護
まずは自助、次に共助、最後に公助

https://igcj.jp/meetings/concept-for-security.pdf

122