Contenu connexe Similaire à クラウドインフラに求められるセキュリティ (20) Plus de Miho Yamamoto (20) クラウドインフラに求められるセキュリティ6. 個人(カッコ内は総合順位) 順位 組織(カッコ内は総合順位)
インターネットバンキングや
クレジットカード情報の不正利用(1)
1 標的型攻撃による情報流出(2)
ランサムウェアを使った詐欺・恐喝(3) 2 内部不正による情報漏えいとそれに伴う業務停止(8)
審査をすり抜け公式マーケットに紛れ込んだ
スマートフォンアプリ(7)
3 ウェブサービスからの個人情報の窃取(4)
巧妙・悪質化するワンクリック請求(9) 4 サービス妨害攻撃によるサービスの停止(-)
ウェブサービスへの不正ログイン(5) 5 ウェブサイトの改ざん(6)
匿名によるネット上の誹謗・中傷(-) 6 脆弱性対策情報の公開に伴い公知となる脆弱性の悪用増加(10)
ウェブサービスからの個人情報の窃取(4) 7 ランサムウェアを使った詐欺・恐喝(3)
情報モラル不足に伴う犯罪の低年齢化(-) 8 インターネットバンキングやクレジットカード情報の不正利用
(1)
職業倫理欠如による不適切な情報公開(-) 9 ウェブサービスへの不正ログイン(5)
インターネットの広告機能を悪用した攻撃(-) 10 過失による情報漏えい(-)
https://www.ipa.go.jp/security/vuln/10threats2016.html
36. 36
本書に記載した情報は、本書各項目に関する発行日現在の Microsoft の見解を表明するものです。Microsoftは絶えず変化する市場に対応しなければならないため、ここに記載した情報に対していかなる責務を負うものではなく、提示された
情報の信憑性については保証できません。
本書は情報提供のみを目的としています。 Microsoft は、明示的または暗示的を問わず、本書にいかなる保証も与えるものではありません。
すべての当該著作権法を遵守することはお客様の責務です。Microsoftの書面による明確な許可なく、本書の如何なる部分についても、転載や検索システムへの格納または挿入を行うことは、どのような形式または手段(電子的、機械的、複
写、レコーディング、その他)、および目的であっても禁じられています。
これらは著作権保護された権利を制限するものではありません。
Microsoftは、本書の内容を保護する特許、特許出願書、商標、著作権、またはその他の知的財産権を保有する場合があります。Microsoftから書面によるライセンス契約が明確に供給される場合を除いて、本書の提供はこれらの特許、商標、
著作権、またはその他の知的財産へのライセンスを与えるものではありません。
© 2017 Microsoft Corporation. All rights reserved.
Microsoft, Windows, その他本文中に登場した各製品名は、Microsoft Corporation の米国およびその他の国における登録商標または商標です。
その他、記載されている会社名および製品名は、一般に各社の商標です。
Y
A
X B
Notes de l'éditeur 年間1000件以上の情報漏洩事件が発生し、7割以上の企業が自社の情報セキュリティに不安を持っています。
すでに従来の FW やアナログなルールだけでは IT は守り切れない状況となっています。
セキュリティ的にどうなんでしょうね~
コンプライアンス的にどうなんでしょうねぇ~
ガバナンスは効かせられるんでしょうかねぇ~
本セッションでは、IT の進むべき方向性をセキュリティ観点でお話しいたします。
なんでもかんでも守ろうとする
守りたいモノが何なのかを特定しましょう
漏洩してもよいものは無視する
異常に厳しいルールで縛ろうとする
ルールを作るのは楽しいかもしれません
「お酒を飲むなら PC を持ち歩かない」?どうせ守られません
“うっかり”は避けられません
知らないうちに社員の生産性を落としていませんか?
ITは生産性を高めるためのものだったはず! 主体は本人。データの重要性はデータのオーナーが判断すべき。
セキュリティ担当者やシステム管理者が決めようとするから無駄なルールが増える。なぜならば見えない領域をすべてカバーしようとするから。
セキュリティ管理者はシステム全体のセキュリティポリシーを策定する。
・「重要なデータは暗号化する」
・「PCのハードディスクは暗号化する」
赤でかこったところがクラウドが関与しているエリア。 クラウドのセキュリティと一言で言ってもいろいろな要件があります。
例えば、物理攻撃。弊社日本には東日本と西日本の2つのリージョンがあるんですけど、その2つのデータセンタが物理的に攻撃されたときどうなるの?って皆さん心配になりませんか?
弊社のデータセンタは、一言で言うとかなり攻撃されにくいようになっています。
首都圏の都市の地下には巨大なネットワークの土管が埋められているのですが、その土管から地上に出た時なんかがスパイ映画であるような攻撃対象になったりするわけですよ。
じゃ、地上に回線這わせなきゃいいよねってわけで、土管から直接引き込めるところにデータセンターを建てています。
物理的にどれだけ堅牢なの?というお話であれば、弊社ではデータセンター見学ツアーというのもやっています。もちろん冷やかしでの見学はお断りをしているのですが、条件がきちんと合えばご覧いただけるようになっています。
外部からのアクセスを制御したいというニーズに対しては、ネットワークセキュリティグループというFWのような機能を使って受信と送信ポートと元のIPレンジ含めて制御することができます。Active Directory のFederation Service のクライアント証明書を利用することでクライアント証明書での接続制限を行うこともできます。 仮想ネットワーク、サブネットにVMを配置した状態はそれなりに強固な状態です。Linuxでは22番でしか接続はできません。
ただし、パブリックネットワークに対して接続が可能ですので、安全とは言い切れない状態です。
Linux VMでは作成時にパスワードか、鍵認証かを選択できますが、パスワードにした場合はブルートフォースアタックのリスクがありますので、あまりおすすめできません。
centOSにはiptablesやfirewalldがありますが、iptablesはこのような状態です。firewalldは設定されておらず、不活になっています。もちろん利用できます。 一方windowsではどうでしょうか。RDPはssh同様に初めからオープンです。まずはこれがないとね、というものですし。
ネットワークのタイプとしては、パブリックネットワークにある、というステータスになっていますね。制限がかかる環境なので、割と安全と言えます。
その代わり、利用する際には手間をかけないとうまく動かないことがあります。
Windowsサーバーのファイヤーウォール設定はこのようになっています。(画面出す)
CoreNetworking / RemoteDesktop / Windows Remote Management がオープンの様ですね。
まだ何もロールを与えていない素のサーバーなので、このような状態です。
Linuxに比べるとやや硬いように思いますが、RDPがパスワード認証であることを考えると、そこはちょっと危ういですね。 linuxVMを作成したとき、ネットワークセキュリティグループではsshのAllowルールが自動的に作成されています。これはNICにかかっています。
下の段の画像はwindowsです。
Windows VMを作成した場合は、RDPがあらかじめAllowの状態で追加されています。
ソースが任意であることに注意してください。この時点ではどこからでも接続が可能になっています。もし単純なID/パスワードで作成したとすれば非常に危険な状態です。
WindowsServerでもadministratorのIdをセットしておけるので、builtinとは違う名前にしましょう。
また、ソースに関してですが、VMが配置されるサブネットで制限をかけていない場合は、いちはやく制限をかけてください。 ネットワークセキュリティグループには既定のルールがあり、普段は隠されています。
「既定の規則」というボタンを押すことで隠れていたものを表示できます。
//タグの話もする。
(めくる) 送信規則のデフォルトはこのようになります。
Vnet、Internetに対するTCP,UDPの通信はすべてが可能です。一番下にすべての送信に対するブロックが入っています。
65001と65500の間にルールが入れられそうに見えますが、ユーザーには100-4096しか許可されていないので、入れることはできません。また、既定のルールを編集することはできません。
少なくともユーザーが利用を開始するにあたって最低限の状態、というのが標準的な状態です。
とはいえ任意のネットワークから接続できてしまうので、あらかじめサブネットのNSGに接続元を縛るルールを入れておけば、準備当初からある程度のセキュリティ水準を用意できることになります。
NSGにも診断ログが付きました。監査ログと同様に、ストレージアカウントにファイルとして保存されます。
メニューの診断から設定をOnにして、取得したいログをチェック、日数を決め、ストレージアカウントをセットすると利用が開始できます。最長一年間の取得が可能です。
CPU、Memory、Disk I/Oなどの性能指標は仮想マシン単位で取得可能。
ただし、OS内のプロセスやパッチ情報などは取れないため、監視はOMS、SystemCenter、セキュリティセンター(Azureのサービスで提供)、3rd party(JP1など)などを利用する必要あり。
Windows: Windows UpdateやWSUSによりお客様自身でやって頂く必要がある。また、ロードマップ的には、近々OMSでパッチ適用が可能になる可能性もあり。セキュリティセンターとOMSでバッチレベルの監視可能。MS推奨バッチが当たってないときは通知。
Azure セキュリティセンター:https://azure.microsoft.com/ja-jp/documentation/articles/security-center-recommendations/
Linux: 同様に別ソリューションでお客様が当てる必要あり。
DDoSについてはユーザーの皆様からは見えない形で防御を行っており、SYN Cookies、レート制限、接続制限などの検出および緩和を提供しています。
その先のEndPointから先についてはアプリケーション層の防御が必要ですが、さまざまな利用形態が想定されることから、azureとしては暗黙なセキュリティ対策は実施していません。WAFの仮想アプライアンスの利用であるとか、NSGを用いてフィルタをかけるなど、そのようなツールをもちいて、皆様自身で防御する必要があります。
Detection Methodologies
Threat Intelligence (e.g. C&C, Botnets, Known Patterns)
Behavioral Analysis (e.g. Suspicious User/Process Executions)
Anomaly Detections (e.g. Baselines)
Detection Fusion (e.g. Kill Chain Analysis)
Monitored Areas:
Virtual Machine Events/ETW
Network Traffic
Azure Resources Audit Logs