Recommended
More Related Content
Similar to 2017 05-16-publish
Similar to 2017 05-16-publish (20)
2017 05-16-publish
- 1. Slide 1 SELinuxの創生 さとう よしひろ Copyright 2016-2017 Yoshihiro Satoh (よしひろ.com/)
- 2. Slide 2 発表者紹介 佐藤慶浩（さとう よしひろ） フリーランス・コンサルタント 略歴：Trusted OSを商用利用するための設計手法を開発した後、Linuxのセキュア OS化製品を開発し、米国Network Computing誌の2003年Well-connected awardsのFinalistを受賞。日本HPのチーフ・プライバシー・オフィサーを務めなが ら、内閣官房情報セキュリティ指導専門官などを併任した後、2016年に同社を退 職して、現在はフリーのコンサルタント。 レジメは https://yosihiro.com/profile/resume.html オフィス四々十六（ししじゅうろく） 代表 元 株式会社 日本HP アジア地域プライバシーオフィサー 元 日本ヒューレット・パッカード株式会社 アジア地域ITセキュリティソリューションマ ネージャ 元 内閣官房情報セキュリティセンター（NISC） 内閣情報セキュリティ指導専門官 Copyright 2016-2017 Yoshihiro Satoh (よしひろ.com/)
- 3. Slide 3
- 4. Slide 4
- 5. Slide 5 発表内容 軍用のTrusted OSは、どうやって生まれ、 それがなぜ商用利用され、 何を期待されてSELinuxが開発されることに 至ったのか Copyright 2016-2017 Yoshihiro Satoh (よしひろ.com/)
- 6. Slide 6 Trusted OSTrusted OSTrusted OS
- 8. Slide 8 米国防総省調達基準から国際規格へ Copyright © 2017 Yoshihiro Satoh (よしひろ.com/) 改定 Common Criteria V1.0 Common Criteria V2.0欧米５ヶ国が基準を統一 １９８５ １９８８ １９９１ １９９４ １９９８ ２０００ ISO/IEC15408 国際標準に 米国基準 (TCSEC) 制定 カナダ基準 (CTCPEC) 制定 欧州基準 (ITSEC) 制定
- 9. Slide 9 TCSEC の Division/Class の要件 （抜粋） Copyright © 2017 Yoshihiro Satoh (よしひろ.com/) A1 : Trusted Distribution CMW: Information Labels CMW: Compartment Mode B3 : Access Control List B3 : Trusted Recovery B3 : Trusted Facility Management (Security Administrator, 2KeyLock) B2 : Device Labeling (Labeling to all models) B2 : Subject Sensitivity Labels (Labeling to all models) B2 : Least Privilege B1 : Trusted Path B1 : Mandatory Access Control B1 : Labeling C2 : Auditing C2 : Strict Password C1 : Discretionary Access Control C1 : Identification and Authentication D: No Access Control Trusted OS
- 12. Slide 12 任意アクセス制御の問題 極秘 秘 非機密 (秘) へのｱｸｾｽ 権限のある人 (秘) へのｱｸｾｽ 権限のない人 秘 非機密 (秘) が流出 する経路がある
- 16. Slide 16 任意ｱｸｾｽ制御 と 強制ｱｸｾｽ制御
- 17. Slide 17 Import & Export リムーバブル・メディア プリント・アウト テープ・デバイス プリンタ・デバイス ﾈｯﾄﾜｰｸ･ﾃﾞﾊﾞｲｽ
- 18. Slide 18 BLS の Sensitivity Level の設計 （定義） マル秘 極秘 社外秘 最高機密 情報の格付け Classifying Information
- 19. Slide 19 用語：Clearance と Sensitivity Level Subject （主体） Object （客体） アクセス
- 22. Slide 22 TCSEC と CMW の関係 SecureWare社 ｾｷｭﾘﾃｨ技術 ｵﾚﾝｼﾞ ﾌﾞｯｸ ｸﾞﾘｰﾝ ﾌﾞｯｸ ﾚｯﾄﾞ ﾌﾞｯｸ DIA-CMW ﾚｲﾝﾎﾞｰ･ｼﾘｰｽﾞ OSF/1 Trusted Unix … POSIXP1003.6 TCSEC TCSEC (Trusted Computer System Evaluation Criteria) DDS-2600-5502-87 CMWEC (Compartmented Mode Workstation E.C.) DDS-2600-6243-91
- 23. Slide 23 CMW の Sensitivity Level の設計 （定義） マル秘 極秘 社外秘 最高機密 営業 人事 経理企画 開発 ←Compartment （種別）→
- 24. Slide 24 マル秘 マル秘 極秘 社外秘 最高機密 営業 人事 経理企画 開発 極秘 社外秘 最高機密 営業 人事 経理企画 開発 Clearance と Sensitivity Level ← Subject（主体） Object（客体）→
- 27. Slide 27 Classification と Compartment Compartment（横軸）→ * CMW TAC4 調達の例 Classification（縦軸） TOP SECRET (TS) SECRET (S) CONFIDENTIAL (C) UNCLASSIFIED (U) NATO ALPHA SIOP ULTRA(UL) SAC TRIDENT(TR)
- 28. Slide 28
- 29. Slide 29
- 34. Slide 34 フ ァ イ ア ー ウ ォ ー ル 外部ネットワーク との境界 インターネット DNS やメール フ ァ イ ア ー ウ ォ ー ル 社内 DataBase サーバ 社内クライアント DMZ (非武装地帯) この要求を許すことが 武装解除を意味する 監視していなければ、 インターネットと変わらない ファイアウォールの効用と限界 DMZの正しい理解
- 35. Slide 35 フ ァ イ ア ー ウ ォ ー ル 外部ネットワーク との境界 インターネット Web サーバ フ ァ イ ア ー ウ ォ ー ル 社内 DataBase サーバ 社内クライアント DMZ (非武装地帯) 社内からアクセス要求するなら、 データのアップロード＆ダウン ロードとも問題ない ファイアウォールの効用と限界 DMZの正しい理解
- 36. Slide 36 フ ァ イ ア ー ウ ォ ー ル 外部ネットワーク との境界 インターネット Web サーバ バックエンド サーバ フ ァ イ ア ー ウ ォ ー ル 社内 DataBase サーバ 社内クライアント DMZ (非武装地帯) これも非武装と みなすのが堅実！ ファイアウォールの効用と限界 DMZの正しい理解
- 37. Slide 37 CMW OSによる境界防御 インターネットサーバ用の強力な境界防御策として CMW OSを導入できます。 ソリューションの考え方：ネットワーク・ダイオード インターネット CMW OS 社内ネットワーク F/W 双方向のアクセス要求をそれぞれに特化した技術で防御します
- 39. Slide 39 積極的に使用しているBLSの機能 データ・セパレーション(Classification) 強制アクセス制御（Mandatory Access Control） 最小特権（Least Privileges) スーパユーザ無効化(2 Key Lock) 最高保護扱いの監査記録(WRITEUP) 不可避の潜在的問題 データ流出(Covert Channels) Trusted OSの活用と限界
- 42. Slide 42 セキュアＯＳ 標準ＯＳ用 アプリ （Ｗｅｂなどを 含む） カスタマイズ モデル３－１ 標準ＯＳ用アプ リを修正せずに、 どこまでできる のかを検討 標準ＯＳ 標準ＯＳ セキュアＯＳ セキュリティ強化 標準ＯＳ用 アプリ （Ｗｅｂなどを 含む） 標準ＯＳ用 アプリ （Ｗｅｂなどを 含む） 標準ＯＳ用 アプリ （Ｗｅｂなどを 含む） 現状 モデル１ モデル２ 標準ＯＳのまま で、どこまでで きるのかを検討 ＯＳだけをセ キュアＯＳにし て、どこまでで きるのかを検討 セキュアＯＳ セキュアＯＳ 対応 アプリ モデル３－２ アプリをセキュ アＯＳ対応させ ると、どこまでで きるのかを検討
- 43. Slide 43 アプリ一体型 セキュアＯＳ モデル３－２ を 一体化 モデル４－２ 汎用ではなく、 特定用途に特 化したものなら、 どこまでできる かを検討 アプリ一体型 セキュアＯＳ モデル３－１ を パッケージ化 モデル４－１ 汎用ではなく、 特定用途に特 化したものなら、 どこまでできる かを検討 標準ＯＳ 標準ＯＳ用 アプリ （Ｗｅｂなどを 含む） 現状 モデル１の例 Bastille lockdown モデル２の例 （任意のセキュアＯＳ） モデル３－１の例 Trusted Solaris, PitBull モデル３－２の例 SPAWAR モデル４－１の例 Virtual Vault モデル４－２の例 （ワープロ専用機） （モデル４－Ｘは、 アプライアンス装置のようなもの）
- 44. Slide 44 標準ＯＳ セキュリティ強化 標準ＯＳ用 アプリ （Ｗｅｂなどを 含む） モデル１ 標準ＯＳのまま で、どこまでで きるのかを検討 セキュアＯＳ 標準ＯＳ用 アプリ （Ｗｅｂなどを 含む） モデル２ ＯＳだけをセ キュアＯＳにし て、どこまでで きるのかを検討 モデル１ モデル２ できること BOF攻撃の一部防止 (stack execution protection) できること 侵害時の アプリの改ざん防止 内外接続での防御 アプリの実装不具合に よる事故の防止 できないこと 侵害されたら、全権を 取られる 監査証跡の保全が技 術的には担保されない できないこと アプリのデータを個別 には保護できない（全 体データを一括してなら 保護できる） 課題 運用ツールの追加開発 や運用手順の増加を伴 なう 課題 アプリの標準サポート アプリ以外の市販品の 使用制限（運用管理 ツールなど）への対応
- 47. Slide 47 運用に与える影響 市販の運用ツールとの互換性がなくなると、運用の作業効率が低下す る 高可用性機能や市販の管理ツールの互換性がなくなると、それらが手 動作業対応となり、運用工数が増大する 運用要件の明確化とそのための専用ツール開発が推奨される（近年の システムでは、運用手順を明確にせず、作業者判断に柔軟性を持たせ るようにしている場合がある。しかし、セキュアＯＳを採用する場合、本 来は自由度の高い管理権限を与えるべきではないので、ロールベース の作業内容に特化した運用ツール開発をすべきである。たとえば、ログ インしてバックアップ・コマンドで領域を指定して実行するのではなく、特 定の領域しかバックアップできない専用ツールを開発するなど） デュアルロック等 provisioning 関連の運用工数の増大 ただし、一部運用工数は専用ツールを開発することで、逆にセキュアＯ Ｓではない場合に比べて削減できる場合がある（一度の開発と、継続 的な運用工数をＴＣＯ的にどう認識するかによる）