この記事は公開されてから1年以上経過しています。情報が古い可能性がありますので、ご注意ください。
こんにちは、臼田です。
皆さん、日々AWSでのセキュリティについて考えていますか？(挨拶
今回は2019年9月25日に開催されたAWS Security Roadshow Tokyo 2019に参加してきましたので、午前のセッションをレポートします。
はじめに軽く感想を述べておくと、先日行われたre:Invent 2018やre:Inforce 2019から言われているような「Builders」「ゲートからガードレールへ」というキーワードが非常に強調され、AWSから私達がどのようにこれからのAWSセキュリティと付き合っていくべきかという道標が明確に打ち出された、とてもいいイベントだったと感じました。
なお、午後については併催されたSecurity JAMに参加したためレポートはありませんのでご容赦ください。
オープニングトーク
アマゾン ウェブ サービス ジャパン株式会社 技術統括本部 レディネス＆テックソリューション本部 本部長 / プリンシパルソリューションアーキテクト 瀧澤 与一氏
- 世の中の変化
- クラウド・バイ・デフォルトの原則が出ている
- 日本で10万以上のお客様にAWSを利用してもらっている
- 業界に縛りはない
- 基幹システムでも使われている
- クラウドジャーニーにおいてもセキュリティは重要
- クラウドを活用する時代のセキュリティ対策は今までと同じでいいのか？
- 環境が変わっているならリスクが変わるので、同じ部分もあれば変わる部分もある
- AWSでは責任共有モデルの考え方がある
- ゲートからガードレールへ
- これまでの境界線での防御はクラウドでは向かない
- ガードレールを整備することが必要
- その一つがAWS Control Tower
- 新しいAWS環境を素早くセットアップし設定可能
- 継続できなポリシー管理を自動化
- ポリシーレベルの概要を確認可能
- AWS Security Hub
- 集約された検出結果で時間を節約
- 自動化されたチェック
- コンプライアンスの向上
- 検出結果に素早く対応可能
- セキュリティ対応の自動化
- クラウドであれば実現可能
- 変化に合わせていろんな事ができる
- Roadshowの対象者
- 色々書いてある
- 金融機関、ヘルスケア、公共部門を含む、セキュリティの専門家及び監査担当者等
- 企業内の情報システムの運用にあたり、セキュリティ、コンプライアンスをご担当される皆様
- AWS に限らず、クラウドを利用する際のセキュリティ統制の最新動向に興味のある皆様
- AWS の利用を前提とした場合のセキュリティ統制のベストプラクティスに興味のある皆様
- セキュリティおよびコンプライアンスに興味のある皆様
- セキュリティに関する意思決定に関わる管理職や役員の方
- これらをまとめてBuildersと表現する
- 関わる人すべてが創っていく側になる
- セキュリティ対策どうやって行くかを考えて実践していく人たちになってほしい
- 色々書いてある
- 何をやるか
- セキュリティの中にはいろんなキーワードがある
- サイバーセキュリティ
- イノベーションとセキュリティ
- ベストプラクティス
- コンプライアンス
- GRC
- セキュアアーキテクチャ
- 発見適当性
- 脅威の予測
- セキュリティ監視
- JAMを併催している
- 権限管理、自動化、インシデントレスポンスなどをゲーム形式で体験するイベント
- いろんな変化が起きている中でセキュリティは特に重要
- Buildersとしてアクションを起こしやすいようなイベントにしている
- AWSのセキュリティの方向性を学んでほしい
DX 時代におけるサイバーセキュリティ
PｗCあらた有限責任監査法人 パートナー システム・プロセス・アシュアランス部長 岸 泰弘 氏
- DXとは
- デジタルが会社を巻き込んだイノベーションを生む、大規模な構造改革である
- 政府としてもSociety5.0とよんでいる
- キーはサイバーとフィジカルの融合がポイントの一つ
- ボーダーが曖昧化
- 国の間や企業間など
- ビジネス部門主導
- イノベーション
- SoE & SoR
- ビッグデータの集約
- アジャイル
- 政府の動向
- 政府主導でDXの安心かつ安全な仕組みづくりを推進している
- 政府自体がDXする
- そして日本全体のDXを推進
- 未来投資戦略2018など
- DX推進ガイドラインで企業のDXのための評価指標を公開
- どうやって行くかというところでクラウド・バイ・デフォルト
- クラウドサービスの安全性評価
- 個人情報保護法
- DXのインパクト
- Digital Builder
- ユーザ主導、ビジネス部門主導
- ユーザはただ使うだけでなくBuildersとなる
- 自分で欲しい物を自分で作る
- IT部門はテクノロジー面でサポート
- Cyber Security
- 継続的な対応
- 対応の自動化
- Digital Economy
- テクノロジーはつながっていく
- ガバナンスをどうしていくかが大切
- Digital Builder
- DX時代のセキュリティにおける課題
- DXとセキュリティ人材の不足
- ビジネス・ITのみならずそれらに関連するリスク評価に精通した人材が必要となる
- ビジネススキル
- リスク評価スキル
- いちばん重要なのはセキュリティだが、利用する観点だけでなく自分で作るためのセキュリティのスキルも必要
- テクニカルスキル
- ビルドするために必要
- RPAなどはあるため比較的わかりやすくなっているが一定のITレベルは必要
- これまで必要とされてこなかったが、ITとビジネス両面に理解のある人材の確保がより重要
- 企業内における推進と役割
- サプライチェーンへの対応
- 多様な関係者を巻き込んだ管理が必要となる
- 全体的なセキュリティを考えるのは難しい
- DXとセキュリティ人材の不足
イノベーションドライバとしてのセキュリティとはーこれからのクラウド利活用における課題整理ー
パネルディスカッション
- パネラー
- Japan Digital Design 株式会社、CTO 楠 正憲 氏
- マネーツリー株式会社、最高プラットフォーム責任者・共同創業者 マーク マクダッド 氏
- 内閣官房内閣サイバーセキュリティセンター内閣審議官 三角 育生 氏
- モデレーター
- PｗCあらた有限責任監査法人 パートナー システム・プロセス・アシュアランス部長 岸 泰弘 氏
パネラーの自己紹介等
- 楠さん
- MUFG社内のイノベーションラボをやっていたが人材の確保など大変なのでJDD設立
- BizLending
- 中小企業向けのオンライン融資サービス
- 新たなビジネスモデルへのチャレンジ
- 銀行本体のデータレイクとは別でプロジェクトを進めた
- データ保護における重層防御の例
- S3とKMSの管理権限の分離によって実装
- 鍵もBYOKを入れたり
- JDDにおけるセキュリティ対策の試み
- 規程類を銀行に合わせるかの議論があったが、クラウドに合わせた
- 一個一個の要件を確認しながら調整
- 日々の業務もリモートで利用することなどを想定
- ゼロトラスト
- マークさん
- Moneytreeの創業メンバー
- Moneytreeは1からAWSで構築
- 個人向けと企業向けの2つのサービス
- 個人向けの有料機能とMT LINKという企業向けで収益を上げる
- MT LINKを採用した企業は50社以上
- 銀行や会計ソフトなど
- 企業もMoneytree内部のセキュリティ・コンプライアンスを気にする
- 取り上げたいセキュリティに関する取り組み
- チェックリスト型のセキュリティ
- 目的と手段が逆転しやすい
- ガードレールに変えていくべき
- 情報セキュリティ部門及びコンプライアンス部門の新技術に関する教育、人材育成
- Buildersになっていくこととも関係するが、判断する側が適切に理解しないといけない
- 情報セキュリティリスクを減らすためのベストプラクティスエンジニアへの教育
- リスクについて理解していないといけない
- チェックリスト型のセキュリティ
- 三角さん
- ビジネスイノベーションに対するサイバーセキュリティの課題
- よくサイバーセキュリティは妨げになると言われる
- サイバーセキュリティが業務等への障害になるべきではない
- 年金機構の事件がわかりやすいが業務が円滑に実施できる仕組みになっていないとセキュリティが阻害される
- クラウドサービス導入に対する課題の内容
- セキュリティを課題とする意見が多い
- 一方でクラウドを使う理由でセキュリティ強化も挙げられる
- クラウドサービスの安全性評価制度の効果
- 調達省庁で共通的にリスク評価
- 自らが行う管理策を特定
- 安全性評価制度の基本的な流れ
- 国際基準等をふまえて策定した基準に基づいて監査
- 2020年秋には開始したい
- セキュリティ体制・人材に関する概念整理例
- 人材教育にフォーカスを当てがちだが、経営層に刺さるように伝えられる戦略マネジメント層も育成しないといけない
- ビジネスイノベーションに対するサイバーセキュリティの課題
パネル
- テーマ
- 現在のクラウドセキュリティはデジタル化の促進、イノベーションの加速の観点でどのような課題があるか
- デジタル化を推進するためにはクラウドセキュリティの位置づけはどのように変わっていく必要があるのか
- 日本の現状を踏まえたときどうすればセキュリティへの取り組みを高度化できるのか
- ビジネスサプライチェーンを考えたときセキュリティはどのようにあるべきなのか
- どのような課題があるか
- 楠さん
- JDDは名前にデザインとあるように元々デザインなどはやるが、セキュリティは外に出したかった
- しかし蓋を開けると、逆にベンダーに教えることが多かった
- 従来のベンダーはキャッチアップしてマニュアル作る
- クラウドの世界は毎日新しいものが生まれる
- キャッチアップしてデリバリーできるベンダーは非常に少ない
- 現状はキャッチアップできる人にトレーニングの機会を設けつつどんどん採用している
- エコシステムとして誰がトレーニングして誰がそれを受けるかが回っていないことが問題
- 新しい技術を学ぶことを組織的にやらなくてはいけない
- マークさん
- 人材調達についてMoneytreeのコツ
- 英語で開発しているのでグローバルで人材調達出来ているのはメリット
- 世界のAWSができるエンジニアをリクルート
- 日本に来たい人は海外でも多い
- 外部は外部でも日本国外は結構いい
- スタートアップ目線での人材育成
- オンプレとクラウドのセキュリティの考え方がある
- どうクラウドを生かしてシステムを提供していくかを考える
- AWSのアカウントで簡単なシステムを作るのは直ぐにできる
- オンプレエンジニアは居心地がいいといってそのまま寝かせておかない
- サーバレスなど新しい取り組みをキャッチアップ
- AWSのようなエコシステムを利用してシステム運用をなくすような戦略を取る
- 人材調達についてMoneytreeのコツ
- 三角さん
- 人材面でいうと国家公務員は日本人でないといけないところがネック
- 年金機構事件以降採用と育成は強化しているがまだまだ
- よく理解してない人と、逆に理解している人が出てきている
- 間に立って理解できる人がいないところは課題
- 楠さん
- どのように変わっていく必要があるか
- 楠さん
- ガードレールは大事だと思う
- 業界ごとにチェックリストはある
- 企業毎にも自分で書き足している物がある
- これまではそれぞれ違うものを調達していたが、ある程度共通の基盤(AWS)で実現できるようになると、そのポリシーを機械で読めるフォーマットにしてシステム的にできる
- 日本語でどうこうというルールはブレがあるから良くない
- フィジカルに出来ないようにすべきことを出来ないように
- AWSでいうと例えば
- CloudFormationを用意しておいてガードレールを適用、業務ごとに少しカスタマイズするだけにする
- GuardDutyを使うなどを活用して実際に出来ているかにフォーカスするべき
- 言い訳のセキュリティは卒業すべき
- ルールはあってもいいが、機械的にできるところを機械に落とし込まないといけない
- 人でしか出来ないことに人を注力させる
- 人手不足に対するアプローチとしてそのような手法が有効
- マークさん
- CloudFormationの話があったのでInfrastructure as Codeから発展してCompliance as Codeがある
- Moneytreeではインフラもyamlで書いてコード管理
- 開発と同じ承認プロセスを得ている
- いわゆるDevOps
- ISO27001などで記載されていればチェックリストではなく標準等でカバーするべき
- 楠さん
- どうすれば高度化していくか
- 楠さん
- この10年のセキュリティエンジニアは結構出てきている
- 実は別のところにボトルネックがあるのではないか
- ビジネスオーナーなどが自分たちが満たすべきものをきちんと言語化出来ているか
- チェックリストが育っているが本当にポリシーではなかったりする
- 合理的にシンプルに目的を達成するための要件をビジネス側で出していかないといけない
- そういう事ができるカルチャーづくりも必要
- 今いるタレントの再育成も重要
- 目的に対してともに歩いていく時に、一緒になってお互いリスペクトしながらやっていく必要がある
- この10年のセキュリティエンジニアは結構出てきている
- 三角さん
- セキュリティも大事だが、何をするかがそもそも大事
- 電子化の目的と手段が逆転しがち
- 何が必要かが決まってないと、リスクの評価も適切に出来ない
- 目的を先に書いてHowは後で考える
- フレームワークをどうするか
- 政府でもやろうとすると継ぎ足しになりがち
- 都度再検討する必要がある
- セキュリティも大事だが、何をするかがそもそも大事
- マークさん
- 銀行法改正に取り組んだ
- 新しく電子決済等代行業が出来た
- ISOまでは行かなかったがFISCで項目を整理した
- 銀行法改正に取り組んだ
- 岸さん
- 会社の枠を超えた取り組みも必要
- 金融ISACもあるが、各ISACが機能していくといいのでは
- 楠さん
- みんなこれからどうやっていったらいいか、未来へのアドバイスなど
- 楠さん
- 人材育成に集約するといつの時代も変わらないがそこをやっていく必要がある
- 間にあっていないのはこれまでやってきた事のひずみが顕在化しているのでは
- サプライチェーン、育成など
- セキュリティを守っていくための仕組みやテンプレートを作っていく必要がある
- マークさん
- 今はユーザ部門は新しい技術を使いたいので良いストーリーを作ってチェックリストを騙すようなことをしている
- 監査部門も含めて本当はいい方向に進みたいはずなのでビジネスサプライチェーンをもっと考えていかないといけないのではないか
- 特に経営層が
- 三角さん
- 組織として何がしたいかをしっかり考えなくては
- 原点に立ち返って考え直す文化が必要
- 別段DXだけに限るものではない
- 世の中がどう変化しているかを理解しないといけない
- 楠さん
AWS セキュリティのベストプラクティスと最新情報
Amazon Web Services, Inc. AWS Security Strategist Nathan Case氏
- Nathan氏はなにか悪いことが起きた時にお客様と話す役割
- 守りて必ず固きは、その攻めざる所を守ればなり
- 孫氏
- 本当にできるのか
- 山の頂上で誰も来ないところで守るのは意味がない
- 唯一の安全なシステムはコンクリート製の壁が置かれ武装した警備員がいて鉛で覆われた部屋に密閉するシステム
-
ジーン・スパフォード
- こんな世界もない
-
- Foundationと比較される言葉
- Foundationがあってもすべてを守ることは出来ない
- AWS Security Jamではお客様がチャレンジできる環境でセキュリティの課題に取り組める
- AWSのドキュメントは読みやすいですか？
- 必ずしもそうではないですが、様々な物があるので活用してほしい
- コンプライアンスの資料もあります
- クラウドセキュリティアライアンスなどの業界ガイダンスもある
- オンラインで見れる
- 目指すべき姿
- 状態がいいとはどういうことか
- 活用すべきもの
- Well-Architectedフレームワーク
- NIST サイバーセキュリティフレームワーク(CSF)
- クラウド導入フレームワーク(CAF)
- マルチアカウントへの理解や運用などへの理解が必要
- Well-Archtectedとは
- AWSのベストプラクティスと比較する
- 運用、セキュリティ、信頼性、パフォーマンス、コスト最適化の5つの柱がある
- やるべきことがきちんと出来ているかをチェックする
- 例えばデータサイエンティストがHadoopでデータをこねこねして数日かけて結果が出てくることがいいのか
- 必要ないことを自動化してシャットダウン、コスト最適化するなどを考える
- AWSのソリューションアーキテクトはWell Architectedを提供できます。相談してください
- レビューは無料のサービス
- わずか10分で皆様の利用アカウントのセキュリティを向上
- 1. セキュリティに関する連絡先メールアドレスの更新
- 悲しいのはセキュリティインシデントに気づかなかったというお客様
- 担当者のメールアドレスではなくMLで登録を
- 2. すべてのリージョンでAWS CloudTrailの有効化
- 有効化してS3に保存
- 誰でも書き換えられるS3に保存してはいけない
- ログをセキュアに、確実に追跡できるように
- 3. Amazon GuardDutyの有効化
- 沢山の赤が出たので無効化したお客様がいた
- これは良くない。アーキテクチャを見直すべき
- GuardDutyがアラートを上げたら確実に注意すべき
- GuardDutyではCloudTrail,VPC Flow Logs, DNS Logsをみている
- 有効化した瞬間から機械学習の有効なデータを利用できているわけはない。最初はテンプレートのルールから
- MLとAIによって日常のアクションを認識して、より正確になる
- Security Hubも重要
- Inspector, GuardDuty, Macieの結果を集約できる
- 復数のセキュリティサービスをまたがって動向を確認できる
- 不審な動きをしているユーザに気づいたら止めたりできる
- 有効化すると最初の30日間は無料で利用できる
- 沢山の赤が出たので無効化したお客様がいた
- 4. Amazon S3 Public Access Block
- S3バケットをパブリックにすることは簡単にできてしまう
- もちろんパブリックにしなければいいですが、簡単ではない
- 一番簡単なのはアカウントで分けてパブリックにするS3としないS3を分ける
- アカウント単位でBlockしておくといい
- 5. 可能であれば、IAMアクセスキーの使用停止
- インシデントの大部分がアクセスキーがパブリックなgitに置かれること
- git-secretを使って防止すべき
- アクセスキーに変わるもの
- IAM Role
- SSM パラメータストア
- STS
- インシデントの大部分がアクセスキーがパブリックなgitに置かれること
- 6. 多要素認証の仕様
- ルートへのMFA有効化
- 特権API呼び出し用のMFA利用も可能
- s3:DeleteObjectにMFA利用など
- 7. AWS Organizationsの使用
- お客様のAWSアカウント全体での整合性
- ポリシーを全アカウントにプッシュできる
- パブリックにアクセスできるネットワークの作成を防止したり
- セキュリティ担当者しか本番環境にアクセスできないようにするなど
- 人間は間違えるからなるべく本番環境に入れないようにする
- 1. セキュリティに関する連絡先メールアドレスの更新
- これらの7つの項目を今すぐ検討してください
- スキルを素早く習得するには
- AWSサポート
- プロフェッショナルサービス
- オープンソースソリューション(ThreatResponse Suiteなど)
- 豊富な人材をお探しであれば私達のパートナーが必ずお役に立てます
- セキュリティに特化したパートナーもいます
クラウドコンプライアンスの現在
アマゾン ウェブ サービス ジャパン株式会社 セキュリティアシュアランス本部 本部長 松本 照吾氏
- はじめに - 本日は"誰"のため
- Amazonはお客さまのフィードバックを大切にする
- 是非今回もフィードバックを
- Builders
- ITの文脈だとあんまり言わない
- 単にITのシステムを作る人ではない
- 皆さんはAWSをイノベーションの道具として使っているはず
- AWSを使うことによってサービスを作る垣根がなくなってきている
- 開発者だけでなく元はユーザ部門だった人もBuildersに
- また、制度設計するのもBuilders
- 内部監査はチェックリストを使う
- 現状とポリシーがあってない場合がある
- チェックリストを変えていくのが皆さんの責任ですよ
- 規制を作る側もBuilders
- re:Inforce振り返り
- AWSが今年始めて行ったAWSが主催するセキュリティにフォーカスした学習型カンファレンス
- re:Inventでもそうだが商業的なカンファレンスではない
- お客様に対して学ぶ価値を提供
- re:InforceはセキュリティのBuildersのためのイベント
- セキュリティと言っても幅が広い
- 監査、CxO、セキュリティエンジニアなど
- すべてをフォーカスに入れている
- 規模感
- 6/25,26の二日間
- ボストンで176のブレイクアウトセッションやワークショップなどが実施
- 50過酷以上から8000名のお客様が参加
- 松本氏もCompliance as Codeのハンズオンを担当した
- 注目のセッション
- 殆どのセッションはスライドや動画が公開されている
- AWS Security blogでカテゴリごとに人気の高かったセッション及びリストを公開
- 来年の開催も決定している
- 2020年6月16-17日、テキサス州ヒューストン
- 今からカレンダーに予定を入れましょう
- クラウドコンプライアンスの現在
- 大前提: コンプライアンス is not only 法令遵守
- 利害関係者の期待を理解し、適合するための説明責任を果たすための源泉がコンプライアンス
- 単にエンジニアが頑張ればいいわけではない
- 自分たちに求められているセキュリティを考えられないといけない
- 加速するクラウドファースト
- グローバルで浸透している
- 20を超える政府がそのようにしている
- クラウド化のメリットを活かす方設計などが求められている
- イノベーションの手を緩めてはいけない
- NIST サイバーセキュリティフレームワーク(CSF)の登場
- アメリカでどうやっているか
- CSFがサイバーセキュリティのベースライン
- ISMSを中心としたものから発見的統制へ
- クラウド・バイ・デフォルト原則の発表
- 日本ではこれ
- メリットにセキュリティ水準の向上が含まれている
- Buildersに求められるのは何をしたらセキュリティ水準が上がるのかを理解すること
- 制度設計
- 日本はグローバルな精度も参考にして頑張っているところ
- 大前提: コンプライアンス is not only 法令遵守
- 私達に求められているもの
- 繰り返しになるが変化、変化への適応
- サイバーセキュリティ
- 攻撃者はどんどん進化する
- リスクの変化を素早く掴む
- クラウドジャーニー
- みんな同じようにクラウド化するわけではない
- 重要なのはビジネス価値・ニーズに合わせて変化する、制度を変えていくこと
- 制度を変える人達も学ぶ必要がある
- 制度設計
- 技術革新に対して適用
- 制度が古くてより新しいセキュリティ対策が取り入れられないと本末転倒
- 制度設計におけるチャレンジ - クラウドは障壁ではない
- 日本ではDevOpsやDevSecOpsがまだ浸透してきていない
- サービスをより柔軟に提供する考え方
- Builderは常に学ぶ必要がある
- AWSのHPには監査人のラーニングパスがある
- AWSの提供する無償・有償の各種サービスもある
- GlobalではCloud Audit Academyというものをやっている
- クラウドを監査するのはどういうことなのか、何が求められるのかを説明する
- 日本にも持ってきたい
- AWS Innovateというオンラインイベントもやる
- オフラインだけではない
- セキュリティだけではなくIoTやMLなどBuilderが学びたい様々な内容がレベル別である
- 10/1より公開
- まとめにかえて
- Buildersともう一つキーワード
- ゲートからガードレールへ
- 既存の制度設計は比較的ゲートになる
- ただ制度も変わっていく
- 例えば高速はETCになって速度を落とさなくなった
- ガードレールってどんなものかな、自分たちの組織ではどんなガードレールができるかなを考えてほしい
感想
非常に濃密なセッションの数々でした。
キーワードとして度々出てくるBuilders、ゲートからガードレールへ。
Buildersとは面白い表現だと思いますね。AWSの活用が進んでくると本当にいろんな垣根や境界が曖昧になってきます。インフラとアプリケーションの境目もそうですし、開発と運用保守もですし、ITとユーザなんかもそうです。みんながクリエイティブに、新しいことに挑戦できる環境にあると思うので、まさにみんながBuildersになっていく必要があります。
その中でゲートからガードレールへ転換していくことが求められますが、これはパネルでも特に言われていましたが簡単ではなさそうです。しかしながらAWSでも様々な学習のためのコンテンツもありますし、世の中に情報が出揃ってきています。自分たちに合わせたガードレールを考えていきたいですね。
午後はこの内容より更にDeepDiveしているようでしたのでそちらも資料の公開等に期待ですね！
14
