class: title, smokescreen, shelf, no-footer # 小規模な会社のネットワーク設計 解説 <div class=footnote> </div> --- class: img-right,compact # 業務で使うプロトコルを把握する  (ポータルは社内WWWサーバ) 1. ポータルで出勤ボタン 2. ポータルで掲示を確認 3. ウエブメールのクラウドへアクセス 4. github.comへのアクセス 5. 退勤時もポータルで退勤ボタン 6. 社外からポータルへアクセス可 X. そのほかに調べ物でWWWを使う <br> (特記しませんけど、これはいいよね?) --- class: col-2,compact # 業務で使うプロトコルを把握する <div class=footnote> (脚注) 認証が必須のポータルへのアクセスは、 いまどき80/tcpでのアクセスを拒否して当たり前なので、 INCOMINGの80/tcpは不要という解答も可(むしろ、モア・ベターもといbetter) </div> (ポータルは社内WWWサーバ) 1. ポータルで出勤ボタン 2. ポータルで掲示を確認 3. ウエブメールのクラウドへアクセス 4. github.comへのアクセス 5. 退勤時もポータルで退勤ボタン 6. 社外からポータルへアクセス可 <wbr> - 方向: 社内から社外 (**OUTGOING**) - DNS(53/udp,53/tcp)が裏で動作: 1-5 - HTTP(80/tcp)とHTTPS(443/tcp): 1-5 - SSH(22/tcp): 4 - GitHUBはHTTPSもしくはSSHでアクセス可能(どちらを使うかは各自の環境による) - 方向: 社外から社内 (**INCOMING**) - (社外でのDNSクエリは社内に問い合わせないので無関係) - HTTP(80/tcp)とHTTPS(443/tcp): 6 --- class: img-right,compact # STATIC NAT (INCOMING 443/tcp)  - 右図の(6)の通信は、ルータで**STATIC NAT**と呼ばれる設定が必要です - ルータのグローバルIPが210.128.52.45なので、 社外から社内へのアクセスは、 https://210.128.52.45/ 宛となります - 社内ポータル宛のパケットは、ルータを通過する際にIPヘッダを書換えます。 ただし普通のNAPT(NAT)とは**逆方向に**です - 210.128.52.45宛443/tcpのパケットを - `210.128.52.45 -> 192.168.10.2`と書換え - 社内側へ送信 - 192.168.10.2(ポータル)には、社内からきた通信のように見えます - 返りはルータで再びIPヘッダのアドレス逆変換を行います --- class: col-2,compact # 補足: DNSまわりの実際 - この問題では、 わざとDNSまわりを簡単にしています。 実際には次のような運用をするでしょう - 案1: 自社にDNSサーバを構築 - 案2: 外向けDNSはISPで購入、内向けは自社に構築 - 案1の自社にDNSサーバを構築する場合 - 固定グローバルIPを持っているので会社でDNSサーバを構築してもよいですが、 逆引き(PTR RR)は放置もしくはISP側で運用してもらう必要があります。 また、おそらくPTR分は有料サービスの購入になるので、 外向け分は、半端に自営サーバ運用するより全部ISPの案2がいいのではと... <wbr> - 案2の社内DNSサーバ部分について - 社内用のDNSサーバと参照用DNSサーバを動かします - ポータルのWWWサーバで兼用すると思います - DNSサーバ - ファイルサーバ - DHCPサーバ - サーバソフトウエア - Microsoft Windows Server - Linuxで自作(bind, apache, samba, isc-dhcpd など) --- class: compact # 小規模な会社のネットワーク設計 問題2解説 - セキュリティ上の懸念事項について、いろいろ羅列してみますと... - 当然HTTP(80/tcp)ではなくHTTPS(443/tcp)のみ許可するべき - いまどき暗号化していないなんて！ - Q: HTTPSで使う証明書はどうしよう?お金はかけたくない - A: 社内用途なので暗号化だけすれば十分 -> Let's EncryptでOK - パスワード認証なんかでいいのか? - パスワードのレベルは? パスワードは最低でも英数字こみ12文字以上で - [JPCERT](https://www.jpcert.or.jp/pr/stop-password.html) - [NICTハンドブック(p.22,p.30など)](https://www.nisc.go.jp/security-site/handbook/index.html) - 2FA(二要素認証)を導入するべき - 2FAまで考えると自力実装は面倒なので、すなおに社外のサービスを買う方がよい <div class=footnote> (脚注) などと、つい、技術的細部へのツッコミが先に出る人は甘い(「まだまだだね」) </div> --- class: compact # 小規模な会社のネットワーク設計 問題2解説 そもそも論 - まず社内ポータルアクセスは**必須業務なのか?を問うべき**です - 社内ポータルへのアクセスは何をするものなのでしょう? - 顧客情報や個人情報をあつかうか否か?でも変わりますが普通は扱うでしょう - **業務分析**:ソフトハウスの従業員で外回り(社外に出る)人は一握りのはず <br> たかが数人のために危険を冒す必要があるものか?を検討するべきです - ソフトハウスなら会社で入力してもらえば十分では? -> **そもそもアクセス廃止** - **外回りが多い業種**なら検討する必要があるでしょう e.g. 保険の外交員 - 社外のサービス(いわゆるASP)がいろいろあります - 20世紀ならいざしらず、いまならサービスがたくさん売られています - まずは**INPUT: 日経の雑誌でも読んで**候補の商品名を探す(->営業よんで->見積り...) - L7以外の別解も検討、たとえばL3以下での解決策(**対費用効果しだい**ですけど) - 電子証明書(公開鍵暗号)認証のVPNを張って社内アクセス - 携帯電話網経由でオフィスへアクセス(普通の意味でインターネットを使わない) <div class=footnote> (脚注) お金がかかるので最終的には経営判断になりますが、 セキュリティ案件は利益に直結しない投資なので、 経営者を納得させることが難しい案件です </div> --- class: compact # 小規模な会社のネットワーク設計 アクセス廃止の場合 - 一方的にアクセス廃止で終わりにしてはいけません - 外回りという仕事が無くなるわけではないので、 ノートPCなどで顧客情報や提案書を持ち歩くことへの対策を考えなければいけません。 - ポータルアクセスのメリットがあるとすれば、データを持たずに外出できること - ノートPC: パスワード認証 + なにか - 生体認証?(懐疑的...)もしくは公開鍵暗号なりの別の鍵など2段階以上の認証 - USBメモリを持ち歩くという場合は自動暗号化機能のものにするなどの考慮 - スマホで業務を許す場合 - 私用と別に業務用スマホを支給(業務用スマホのセキュリティレベルは厳しく) - 私物で業務の場合MDM(モバイルデバイス管理)を導入し私用と業務を完全分離 - ちなみに、こういう使い方をBYODと言います(教育業界のBYODとは別物です) - MDMは技術としては仮想環境導入の一種です - 回線費用の一部負担なども考えるべきです(考えない会社はブラック体質だな) --- class: compact # 番外編: 本学の場合 (#12-14むけ情報) - 第12〜14回の参考に、前頁までの事例と大学を比較してみるとよいでしょう - 事務局の人で外回りする人は少数です(前頁までと似ています) - 教員は外出がそれなりに多いですが - 外出先で(学生の)個人情報や成績情報にアクセスする必要がありません - 原則、学内でやってください - いそぎの場合、VPN経由でもアクセス可能 - 基本的に大学というモールのテナントとして研究室があるようなものなので <br> - 基本的に各自きをつけてね、としか言いようがないですね:-) - 特許情報とか握りしめている人は別かもしれませんが、 それは各研究室の案件 - イオンモールだと思ってOK - **大学の設計案件はイオンモール本体の設計**にあたります - テナントの便宜も考えて設計しますが、基本テナントへのネットワーク提供のみ - テナント(研究室)内部の運用は、それは各テナント次第です - **授業のための環境整備はモール本体の案件**になります(最終課題の主目的) --- class: col-2,compact # 参考: 問題1のフィルタルールを書く <div class=footnote> (脚注) TCP/IPの動作を理解していないとフィルタ書けないことが分かってもらえましたかね? </div> - ルータに書くフィルタの設定例 - フィルタの解説スライドにあるCISCOっぽい人工のルール - 192.168.10.2は社内WWWサーバ - ESTABLISHEDはTCPヘッダのACKが1 <br> TCPコネクションの2つ目のパケット(3-wayハンドシェイクの途中)以降を許可 - OUTGOINGのルール3(ESTABLISHED)は社内ポータルへのアクセスの返り - INCOMINGのルール2はDNS(UDP)の返り - 最後にすべてを拒否(DENY ANY ...) ``` 凡例 ACTION PROTOCOL SRC_IP SRC_PORT DST_IP DST_PORT [OUTGOING (社内 -> 社外), ルータ外側Interfaceのout ] PERMIT TCP ANY ANY ANY 22,53,80,443 PERMIT UDP ANY ANY ANY 53 PERMIT TCP 192.168.10.2 443 ANY ANY ESTABLISHED DENY ANY ANY ANY ANY ANY [INCOMING (社外->社内), ルータ外側Interfaceのin ] PERMIT TCP ANY ANY ANY ANY ESTABLISHED PERMIT UDP ANY 53 ANY ANY PERMIT TCP ANY ANY 192.168.10.2 443 DENY ANY ANY ANY ANY ANY ```