20170827jtf

Transcript

1. 合同会社BUSTERWORKS 大喜多 利哉 クラウド時代だから必要な ネットワーク＆セキュリティ
2. 自己紹介 2 大喜多利哉（おおきた としや）  VPNやファイアウォールなどが専門のネットワークエンジニア兼 テクニカルライター  合同会社BUSTERWORKS 代表(http://www.busterworks.co.jp/)  書籍・記事執筆のお仕事絶賛募集中です  本が出ました
3. 本が出ました 3 Mastodon入門ガイド https://www.amazon.co.jp/dp/4800711797/
4. 今日おはなしすること 4  2017年の今日における、ITインフラのセキュリティに対する考え方  クラウドにおけるセキュリティの考え方  クラウドにおけるネットワークの考え方
5. 今日おはなしすること 5  2017年の今日における、ITインフラのセキュリティに対する考え方  クラウドにおけるセキュリティの考え方  クラウドにおけるネットワークの考え方
6. クラウドを使わない理由の上位に「セキュリティ」が挙がる理由 6  総務省公表 平成27年版 情報通信白書 クラウドを利用していない企業の理由2位 「セキュリティに不安がある」 34.5%  「事業者のサービス仕様に委ねることになるため、利用者自身で情報セキュ リティ管理ができない」ことを心配している  でもそれってクラウドに限った話ですか？  ホスティングの世界では大昔からそうですが？  事業者がセキュリティ対策するべき領域と、利用者がセキュリティ対策する べき領域があること、およびそれぞれの範囲を正しく理解するべき
7. 責任共有モデル(https://aws.amazon.com/jp/compliance/shared-responsibility-model/) 7  クラウドソリューションのセキュリティを評価する場合、お客様が以下の点 を理解して区別することが重要です。  クラウドサービスプロバイダー (AWS) が実装および運用するセキュリティ 対策 – "クラウドのセキュリティ"  AWS サービスを使用するお客様のコンテンツとアプリケーションのセキュ リティが関連する、お客様が実装および運用するセキュリティ対策 – "クラ ウドにおけるセキュリティ“  AWS がクラウドのセキュリティを管理している一方で、クラウドにおける セキュリティはお客様の責任となります。お客様は、所有するコンテンツ、 プラットフォーム、アプリケーション、システムおよびネットワークを保護 するためにどのようなセキュリティを実装するかについて管理権限を保持し ており、これはオンサイトのデータセンターのそれとなんら変わることはあ りません。
8. 責任共有モデル(https://aws.amazon.com/jp/compliance/shared-responsibility-model/) 8 https://www.slideshare.net/c95029/awsshared-responsibility-model-16612378 https://d0.awsstatic.com/events/jp/2017/summit/slide/D4T3-4.pdf
9. クラウド導入にあたりユーザーがやるべきこと 9  事業者、ユーザーの負うべき責任範囲の正しい理解  事業者に任せられる部分は任せてしまう 例：AWSのマネージドサービスは、各種セキュリティ認証を取得している PCI DSS認証取得においても、全部自前でやるよりも マネージドサービスに任せられる部分は任せた方が良い場合も  ユーザーの負うべき責任範囲に対する対策 例：S3のバケットに対するアクセス権などはユーザーの責任 IAMの適切な管理もユーザーの責任  密なコミュニケーション 事業者やCIerはクラウド導入の支援をする立場、パートナー 有事の際にどうするか、関係者間の連携
10. 今日おはなしすること 10  2017年の今日における、ITインフラのセキュリティに対する考え方  クラウドにおけるセキュリティの考え方  クラウドにおけるネットワークの考え方
11. 公開サーバのセキュリティ対策 11  クラウドによって簡単にサーバが作れるようになりました  反面、セキュリティが不十分なまま放置されたりするサーバが被害に遭うこ とが増えました  原因の大半は脆弱性(Webアプリケーション、ミドルウェア、OS )  続いて、不正ログイン・アカウントリスト攻撃 図2：公開サーバからの情報漏えい原因別割合（2016年上半期トレンドマイクロ調べ） http://blog.trendmicro.co.jp/archives/13853
12. 公開サーバのセキュリティ対策 – チェックポイント 12  テスト用に立ち上げてそのまま放置しているサーバありませんか？  パスワードがデフォルトのままだったりしませんか？  開発環境を不必要に公開したりしていませんか？  脆弱性診断は定期的に行っていますか？  診断後の対策は適切に行っていますか？  クラウドでもWAFとかIPSとか使えますよ
13. 公開サーバのセキュリティ対策 – 具体例 13  パスワード認証のままのLinuxサーバ →公開鍵認証onlyにしましょう →SSHによるrootログインを不可にしましょう →頻繁にSSHするサーバでなければ普段は閉じておきましょう  ミドルウェア／Webアプリケーション →初期パスワードのままにしておかないこと →定期的なバージョンアップ・パッチ適用など  古いアプリケーション(BIND/qmail) →わざわざクラウドに持ってこないで！ →より脆弱性の少ないアプリケーションの選択 →ちゃんとメンテナンスされているアプリケーションの選択 →マネージドサービス利用への切り換え
14. 今日おはなしすること 14  2017年の今日における、ITインフラのセキュリティに対する考え方  クラウドにおけるセキュリティの考え方  クラウドにおけるネットワークの考え方
15. オンプレのネットワーク
16. クラウドのネットワーク 16 AWS cloud Public subnet #2 10.0.3.0/24 Availability Zone #1 Availability Zone #2 Internet gateway Public subnet #1 10.0.1.0/24 Private subnet #2 10.0.4.0/24 Private subnet #1 10.0.2.0/24
17. 公開サーバのアクセス制御 Source…203.0.113.100:25284 Destination…198.51.100.100:80 ポート80番/接続元Anyと 設定しておけば 戻りの通信もよろしくしてくれる →ステートフル クライアント→サーバのルールと サーバ→クライアントの通信ルールを 両方明示的に書いておく必要がある →ステートレス 方向 ポート/ プロトコル アドレス 可否 Out→In 80/tcp 0.0.0.0/0 Allow In→Out 1024- 65535/tcp 0.0.0.0/0 Allow 方向 ポート/ プロトコル アドレス 可否 Out→In 80/tcp 0.0.0.0/0 Allow NAT配下のクライアントの Source Portはハイポート (1024～65535)から ランダムに設定される
18. まとめ 18  クラウドの正しい知識を得よう  作法の違いを理解して適切なセキュリティ対策を行う  クラウドとオンプレのネットワーク構成の違いを理解し 適切なアクセス制御を行う  クラウド事業者・CIer等のパートナーとのコミュニケーションを密に いざというとき相談出来るようになっていますか？
19. ご清聴ありがとうございました 19