name: overview class: title, smokescreen, shelf, no-footer # 第06回 アクセスコントロール <div class=footnote> <small> </small> </div> --- class: compact # アクセスコントロール - なにを許して、なにを許さないのか?の制御が「<B>アクセスコントロール</B>」 - そのルールをアクセスコントロールリストと呼びます。略して<B>ACL</B> - EC2のセキュリティグループあれがACLです。 <small> <br> あのルールの定番を我々は次のように表現します。 <br> <b>最初に該当したルールが適用</b>されます (これをfirst matchと言います) 1. permit ssh ... SSH(22/tcp)を許可 1. permit http ... HTTP(80/tcp)を許可 1. permit https ... HTTPS(443/tcp)を許可 1. deny all (すべて拒否、画面には表示されていませんが、暗黙のデフォルトルールです) <small> - 「ルール1〜3を試し、どれにもマッチしない通信はルール4.で拒否される」と読みます </small> </small> --- class: compact # ACLの代表例はユーザとネットワーク <div class=footnote> <small><small> (脚注) ネットワークも曖昧な用語ですが、 われわれインフラ屋がネットワークと言う場合、 デジタルデータ転送システムの実体つまりTCP/IPを想定して話をしています。 ポート番号とIPアドレスで判断できるものだけということです。 ユーザなんて関係ありません </small></small> </div> <small> - いろいろなACLがあるわけですが、よく出会う代表例がネットワークとユーザの権限のACLでしょう </small> - ネットワーク ... <small>あくまでも許可する通信は何?という話</small> <small> - サーバと通信できるアプリケーションは何か? - サーバとの通信を許されるクライアントは誰か? - 典型例: EC2のセキュリティグループ </small> - ユーザの権限 ... <small>ウエブやSSHによるログイン後の話</small> <small> - ユーザAは(AWS Consoleで)EC2によるサーバ構築が許されるか? -> AWSの<B>IAM</B> (演習で体験します) - Unix上でユーザBはコマンドXを実行できるか? (次回やります) - Unix上でユーザCは、ファイルZを読み書きできるか? (次回やります) </small> --- class: compact,img-right # 概念図: -ネットワークフィルタの違い- <div class=footnote> <small><small> </small></small> </div> ![](../../images/acl-concept-network.png) <small> - 図(上)は「普通のサーバ」の場合 - ネットワーク側では何も制限しない <br> サーバは"いわゆる"野ざらし状態 - 典型例: サーバ(Unix)のフィルタでSSHとHTTPのみを許可する - 図(下)は「AWS」の場合 - 典型例: ネットワーク側でSSHとHTTPのみを許可する (security group) <br> (注: Unix側はフィルタなし,ノーガード戦法) </small> --- name: aws-security-overview class: title, smokescreen, shelf, no-footer # AWSセキュリティの概要 <div class=footnote> <small> </small> </div> --- class: compact,img-right # AWS利用時の権限の考え方(全体像とまとめ) <div class=footnote> <small> <small> (脚注) IAM = Identity and Access Management <br> 日本人は「あいあむ」と発音する人が多いけれど、海外では「あい、えー、えむ」が普通らしいです </small> </small> </div> ![height400px](/slides/service/aws/academy/images/aws-security-overview.png) - 代表的な使い方が<B>二系統</B>あります <small> - ユーザが管理画面で操作できる権限 - AWSのサーバ(例:EC2)などが持つ権限 </small> - 図中の「(1)(4)と<B>IAM</B>」がAWSの機能 <small> - これらのAWSの機能で守る前提 - IAM ... ユーザに<B>WWW(AWS Console)上で操作する権限を与えるのがIAM</B> - IAMロール ... "擬人化されたEC2ユーザ"にIAM権限を与えるイメージ(下図(4)) </small> - 図中(2)(3)はUnixの世界 <small> - 権限の概念も機能もあるけど、 すごく緩い状態です。 <B>AWSでは使わない</B>と考える </small> --- class: compact # IAM<small>(Identity and Access Management)</small> <div class=footnote> <small><small> (脚注1) 日本人は「あいあむ」と言いがちだけど、海外では「あい、えー、えむ」が普通らしい <br> (脚注2) AWS AcademyではIAMは一切さわれません。ここでは、こういう概念があるぞ!という紹介だけです </small></small> </div> - AWSのサービスを操作できる権限 - <B>誰が、何をできるか?を、かなり細かく設定</B>できます - 例: EC2の操作 <small> - EC2の管理画面を見ることが出来る(見るだけ) - EC2の管理画面で設定変更が出来る - EC2の管理画面で起動/停止が出来る - EC2を管理画面でEC2を削除できる - 注: EC2の上で動いているOSは好きにできます(AWSではなくUnixセキュリティ) </small> - 典型例 <small> - インフラチームは(支払い関係以外は)何でも出来る権限があります。 依頼を受けるとインフラチームはEC2上にOSをインストールし、開発部隊に引き渡します - 開発部隊ができるAWSの操作は「EC2の起動/停止」だけです <br> EC2上のOSの中身は(AWSの権限と無関係なので)開発部隊が好きに変更できます </small> --- class: compact # IAMロール <div class=footnote> <small><small> (脚注) 演習で使う機能だけ紹介しましたが、 IAMとIAM Roleは、もっと奥深いものです。 プロを目指す人は勉強して下さいね:-) </small></small> </div> - 前ページのとおり、IAMとは、たいてい管理画面を操作する権限の設定です - では、自分のサーバから「あるAWSのサービスを使いたい」時は、どうする? <small> - 全部許可は論外だし、 そのつど管理画面で操作するのは面倒(手動操作ありではクラウドではない;-) - -> <B>ふつうのIAMでは、うまくいきません</B> </small> - <B>IAMロール ... AWSのサービスに権限を与える機能</B> - いわば「(EC2などを)仮想ユーザのように扱う」ということですね - 例: (EC2にIAMロールを設定することで)EC2からAWS Rekognitionを利用できる - 例: (EC2にIAMロールを設定することで)EC2からAWS S3を利用できる