「AWS上のセキュリティ対策をどういう順序でやっていけばいいか」という話をしました~Developers.IO 2019 Security登壇資料~ 「AWS上のセキュリティ対策をどういう順序でやっていけばいいか」という話をDevelopers.IO 2019 Securityでした際の登壇資料です。一つの指標としてセキュリティ対策に取り組む方の役に立てば幸いです。
2. アジェンダ • 最近のウェブセキュリティを取り巻く話題 • OWASP Top 10 – 2017を巡る話題 – XXEとSSRF – 安全でないデシリアライゼーション • 割賦販売法改正・施行 • 安全なWebアプリケーションの作り方 改訂 – PDFのFormCalcによるコンテンツハイジャック 2 3. 徳丸浩の自己紹介 • 経歴 – 1985年 京セラ株式会社入社 – 1995年 京セラコミュニケーションシステム株式会社(KCCS)に出向・転籍 – 2008年 KCCS退職、HASHコンサルティング株式会社(現社名:EGセキュアソリューショ ンズ株式会社)設立 • 経験したこと – 京セラ入社当時はCAD、計算幾何学、数値シミュレーションなどを担当 – その後、企業向けパッケージソフトの企画・開発・事業化を担当 – 1999年から、携帯電話向けインフラ、プラットフォームの企画
備考 2018/09/21 22:15 追記 2018/09/20 12:10 に公開した「どうして JWT をセッションに使っちゃうわけ?」というタイトルが不適切だとご指摘をいただいています。 その意見はもっともだと思いますので、現在、適切となるようにタイトルを調整しています。 ご迷惑およびお騒がせをして大変申し訳ございません。 本文の表現についても改善の余地は大いにありそうですが、こちらは (すでにご意見を頂戴している関係で、) 主張が変わってしまわないように配慮しつつ慎重に調整させていただくかもしれません。 はあああ〜〜〜〜頼むからこちらも忙しいのでこんなエントリを書かせないでほしい (挨拶)。もしくは僕を暇にしてこういうエントリを書かせるためのプログラマーを募集しています (挨拶)。 JWT (JSON Web Token; RFC 7519) を充分なリスクの見積もりをせずセッシ
はじめに サイボウズさんの ImageMagick の利用をやめる記事について少し思う所を書きます。否定というよりアシストのつもりです。(2018年08月26日投稿) さようなら ImageMagick 自分のスタンスを3行でまとめると、 policy.xml で読み書き出来るファイル形式を絞れば、いうほど怖くはない ただ、ImageMagick に限らずサーバサイドで動かすのは手間と覚悟が要る Yahoobleed の件でコード品質が信用ならないと言われたら、ごめんなさい 「ImageMagick を外した理由」 サイボウズさんのブログでは、2017年の ImageMagick 脆弱性報告数が多いので駄目との事です。 脆弱性 ImageMagick には脆弱性が大量に存在します。 2017 年に報告された ImageMagick の脆弱性は 236 件 でした。 大量にある上にリモートコ
組織のセキュリティ対策 2018.7.25 あなたはセキュリティ業務に関連する情報(webサイトや資料)を整理できていますか? 情報の移り変わりはとても早く、ご存知の通り情報セキュリティの世界も新しい情報を常にインプットしていかなければなりません。ただでさえ忙しい中、新しい情報をキャッチアップし続けるための手間も最小限に抑えたい、そんな想いを持つ方も多いのではないでしょうか。 そこで、今回は「情報セキュリティ担当者がどのサイト・資料に目を通しておけばいいか」を、下記のような視点から80個厳選してまとめました。 ・セキュリティ対策、インシデント情報、脆弱性情報に関する情報を素早くキャッチしたい ・企画資料のために使えそうな統計データや情報が欲しい ・新人研修のための資料を探している RSS、Social Media、キュレーションサイト等情報の入手方法はいろいろありますが、このような形でまと
はじめに AWSの運用構築をまかされたインフラエンジニアのかたに向けて、セキュリティで考えるべき視点と代表的なソリューションをご紹介します。 AWSでのセキュリティを考える前に、私達自身のセキュリティを考えてみましょう。 "外出前に鍵をかける"、"ひとけのない道はなるべく通らない"など最低限やっておくべき対策があります。 たくさんのお金をかけてボディガードを雇っても、鍵をあけて外出しては意味がありません。 AWSのセキュリティ対策も同様です。 追加のコストを払ってセキュリティソリューションを導入する前に、最低限やっておくべき対策があります。 特に代表的なものをご紹介します。 出所が不明なAMIは使わない EC2の作成元となるAMI(マシーンイメージ)は誰でも公開できます。 中には悪意のあるソフトウェアが含まれるAMIも含まれます。 AWSや信頼できるベンダーが提供するAMIを使いましょう。
こんにちは。池田です。本州からは梅の便りが届いていますが、札幌はまだまだ雪景色です。 最近になり周囲で「今度はEchoの招待が届いた!」とか「2回目のEcho Dotの招待が届いた!」とか「2台目ゲット!」とか聞こえてきました。我が家にEcho Plusを迎え入れる日はいつになるのでしょうか。 早くスマート家電を声で制御する生活を体験したくてワクワクしています。 はじめに 今年に入ってからAWS再入門シリーズと題して勉強を進めているのですが「たまにはAWSホワイトペーパーを読んでみよう」と思い立ちいくつか読んでいた中でAWS_Security_Checklistという資料を見つけました。 内容は非常に簡潔ですが、各項目はそれぞれ関連するAWSドキュメントへのリンクが設けられていました。 そこで今回は資料からの各リンク先ドキュメントを基に筆者が整理したチェックポイントなどを「AWS再入門20
「安全なSQLの呼び出し方」というSQLのセキュリティに焦点を当てたドキュメントが、2010年3月にIPA(独立行政法人情報処理推進機構)から公開された。 これは2006年1月から提供されている、Webサイト開発者や運営者向けのセキュアWebサイト構築のための資料「安全なウェブサイトの作り方」の別冊として書かれたものである。「安全なウェブサイトの作り方」が92ページなのに対して、SQLインジェクションについてだけで40ページもの分量がある。なぜこんなに分厚いのだろうか。 このドキュメント作成に協力したという、独立行政法人産業技術総合研究所 情報セキュリティ研究センターの高木浩光氏にお話を伺うことができた。高木氏は個人ブログ「高木浩光@自宅の日記」で、セキュリティ関連の問題を追求する論客としても知られている。筆者も以前、この連載の「今夜わかるSQLインジェクション対策」の回(2006年11月
「安全なウェブサイトの作り方」は、IPAが届出(*1)を受けた脆弱性関連情報を基に、届出件数の多かった脆弱性や攻撃による影響度が大きい脆弱性を取り上げ、ウェブサイト開発者や運営者が適切なセキュリティを考慮したウェブサイトを作成するための資料です。 「安全なウェブサイトの作り方」改訂第7版の内容 第1章では、「ウェブアプリケーションのセキュリティ実装」として、SQLインジェクション 、OSコマンド・インジェクション やクロスサイト・スクリプティング 等11種類の脆弱性を取り上げ、それぞれの脆弱性で発生しうる脅威や特に注意が必要なウェブサイトの特徴等を解説し、脆弱性の原因そのものをなくす根本的な解決策、攻撃による影響の低減を期待できる対策を示しています。 第2章では、「ウェブサイトの安全性向上のための取り組み」として、ウェブサーバの運用に関する対策やウェブサイトにおけるパスワードの取扱いに関す
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
処理を実行中です
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く