サーバーレスのセキュリティリスク - AWS Lambdaにおける脆弱性攻撃と対策 - Flatt Security Blog
はじめに こんにちは、株式会社Flatt Security セキュリティエンジニアの森岡(@scgajge12)です。 本稿では、AWS Lambda で起こりうる脆弱性攻撃やリスク、セキュリティ対策を解説し、サーバーレスにおけるセキュリティリスクについて紹介します。 はじめに AWS Lambda について サーバーレスにおけるセキュリティリスク AWS Lambda で起こりうる脆弱性攻撃 Lambda での脆弱性攻撃によるリスク 脆弱性攻撃による更なるリスク OS Command Injection XML External Entity (XXE) Insecure Deserialization Server Side Request Forgery (SSRF) Remote Code Execution (RCE) AWS Lambda におけるセキュリティ対策 セキュリティ
AWS Amplify で Custom headers を活用したパフォーマンスと脆弱性対策
はじめにこんにちは、Finatext で保険事業にてプロダクト開発をしている @toshipon です。今回は我々のプロダクトでも活用している AWS Amplify コンソールにおける Custom headers の運用についてお話いたします。 概要Amplify 上で Custom headers を設定する手順についてご紹介いたします。Custom headers は、HTTP レスポンスのヘッダーに指定できる情報を管理するもので、主にデバッグやセキュリティ対策、情報提供に利用されます。 今回は、キャッシュを適切に有効にさせてパフォーマンスを向上させたり、XSSやクリックジャッキング等のWebアプリケーション脆弱性に対処することを目的として利用したいと思います。 また、Content-Security-Policy-Report-Only というセキュリティヘッダー（説明については
GitHub - aquasecurity/tfsec: Security scanner for your Terraform code
As part of our goal to provide a comprehensive open source security solution for all, we have been consolidating all of our scanning-related efforts in one place, and that is Trivy. Over the past year, tfsec has laid the foundations to Trivy's IaC & misconfigurations scanning capabilities, including Terraform scanning, which has been natively supported in Trivy for a long time now. Going forward w
AWS×コンテナで基本的なDevSecOpsアーキテクチャをデザインしたお話 - How elegant the tech world is...!
はじめに 先日、僕が担当する業務でECS/Fargate利用を前提にDevSecOpsアーキテクチャをデザインし、社内のAWS勉強会にて登壇する機会をいただきました。 本ブログでも内容をかいつまんでご紹介できればと思います。 AWSによらず、コンテナを利用されている方にとって、一つのプラクティス例としてご参考になれば幸いです。 ※コンテナ自体の説明や必要性に関する内容は省略していますm(_ _)m そもそもDevOpsとは？ DevSecOpsの導入意義をお伝えするた前に、まず軽くDevOpsの意義をお伝えします。 ※とは言え、この記事をご訪問されている方にとっては「何をいまさら...」な内容かもしれませんし、ググればDevOps自体の情報はたくさん見つかりますので、重要なポイントのみ述べることにします。 DevOpsとは、一言で述べれば、開発チームと運用チームが協力してビジネス価値を高め
【最新】経産省「サイバー・フィジカル・セキュリティ対策フレームワーク」を読み解く
2019年4月18日、経済産業省は「サイバー・フィジカル・セキュリティ対策フレームワークVer.1.0(以下「CPSF」)」を公表しました。 CPSFは、サイバー・フィジカル・システム(サイバー空間とフィジカル空間(現実世界)の双方に影響を与えうるシステム)のセキュリティ対策に必要となるコンセプト、ポリシー、具体的なメソッドを体系的にまとめたものです。 IoTシステム、工場システム、ビルシステム、コネクテッドカー、スマートホームなど、サイバー・フィジカル・システムに関連する業務に携わる方々は、CPSFを参照することで、必要となるセキュリティ対策のポイントを押さえられるようになっています。 その一方、添付資料を含めて262ページというボリュームやユニークな概念(「バリュークリエイションプロセス」「三層構造アプローチ」等)の使用によって、一読しただけではその内容や重要性の理解が難しい可能性もあ
Keybase入門
Nikhita Raghunathによる。PGPの普及を阻んでいた身元の確立と利用の手軽さを、SNSで解決している。 Keybaseのことを聞いてから、私は参加したいと思っていた。残念ながら、私が最初にそれを手に入れようとした際、サインアップに招待状が必要だった。(これを書いている時点で、ウェブサイトのページは別の方法を書いているが、Keybaseは招待状を必要としない。連絡してほしい!) Keybaseのコンセプトは一度理解すれば、理解しやすいようだ。私が最初にそれを聞いた時は混乱した。本当に何なのかを理解するのにグーグル検索が必要だった。この記事で、あなたがKeybaseについて持っている不明瞭な考えを明確にしたいと考えている。 Keybaseとは何か Keybaseは公開鍵の信頼できる保管庫である。もし、私があなたに暗号メッセージを送りたい場合、公開鍵を簡単に見つけることができる。ま
Google - Site Reliability Engineering
Written by: Heather Adkins, Betsy Beyer, Paul Blankinship, Ana Oprea, Piotr Lewandowski, Adam Stubblefield Can a system be considered truly reliable if it isn't fundamentally secure? Or can it be considered secure if it's unreliable? Security is crucial to the design and operation of scalable systems in production, as it plays an important part in product quality, performance, and availability. In
2020年6月に発生したドメイン名ハイジャックのインシデント対応について - coincheck tech blog
はじめまして、サイバーセキュリティ推進部の喜屋武です。 今回は2020年6月に発生したお名前.com上の当社アカウント乗っ取りによる「coincheck.com」のドメイン名ハイジャックのインシデントについて、発覚までの経緯とその後のインシデント対応についてご説明します。 1 発覚までの経緯 1.1 サービスの応答時間の遅延の確認 当社利用のドメイン登録サービス「お名前.com」で発生した事象について（最終報告） | コインチェック株式会社 でもタイムラインを記載しましたが、最初の異変は日頃からモニタリングしているサービスのレスポンスタイムが著しく遅延していたことでした。 当時のサービスのレスポンスタイム この異常を確認し、SRE チームが調査に乗り出しましたがこの段階では他に問題は確認されず、レスポンスが遅延している原因の特定には至っていませんでした。 1.2 他部署やユーザーからの問い
AWS上でどのようにゼロトラストアーキテクチャを考えていくか | Amazon Web Services
Amazon Web Services ブログ AWS上でどのようにゼロトラストアーキテクチャを考えていくか 2021年7月追記： AWSにおけるゼロトラストに関するアップデートされた情報は、以下をご参照ください。 https://aws.amazon.com/jp/security/zero-trust/ また、本Blogを詳細にアップデートしたBlog記事もありますので適宜ご参照ください。 「ゼロトラストアーキテクチャ: AWS の視点」 https://aws.amazon.com/jp/blogs/news/zero-trust-architectures-an-aws-perspective/ —————————————————————– 厳しい規制への対応やリスク回避を考慮事項として擁するお客様は、レガシーアプリケーションのリファクタリングや新しいアプリケーションのデプロイに際
当社利用のドメイン登録サービス「お名前.com」で発生した事象について（最終報告） | コインチェック株式会社
第一報に関してはこちらよりご確認ください コインチェック株式会社（本社：東京都渋谷区、代表取締役：蓮尾 聡、以下当社）は、2020年6月1日に発表したドメイン管理サービス「お名前.com（GMOインターネット株式会社）」の当社アカウントで発生した事象について、事実が判明した時点より、原因の究明および対策を進め、ドメインの登録サービス事業者の移管を実施いたしました。 お客様にはご迷惑をおかけいたしましたことをお詫び申し上げると共に、今後もさらなるセキュリティの強化やサービスの向上により、お客様により安全に・安心してご利用いただけるサービスを提供できるよう努めてまいります。 本件に関する詳細は、以下の通りです。 「お名前.com」で発生した事象 「お名前.com」のドメインやサーバーを管理する「お名前.com Navi」における通信を改ざんできる不具合を利用し、悪意のある第三者が不正にメールア
セキュリティエンジニアへの道：私のキャリアチェンジ物語 / The Road to Becoming a Security Engineer: My Story of Career Change | メルカリエンジニアリング
セキュリティエンジニアへの道：私のキャリアチェンジ物語 / The Road to Becoming a Security Engineer: My Story of Career Change * English version follows after the Japanese こんにちは。メルカリのProduct Securityチームでセキュリティエンジニアをしている@gloriaです。ブログを書くのが随分お久しぶりなのですが、前にQAと自動化テストについて記事をフォローしていた方がいらっしゃったら、当時に自動化テストエンジニアとして書いたISTQBテスト自動化エンジニア認定資格、STARWESTカンファレンス、とAQA POP TALKの記事を読んだことがあるかもしれません。 今回は、自動化テストエンジニアからセキュリティエンジニアへのキャリアチェンジについてお話して、キャリア
金融機関が機密性の高いデータのためにAWS のサービスを承認する方法 | Amazon Web Services
Amazon Web Services ブログ 金融機関が機密性の高いデータのためにAWS のサービスを承認する方法 本投稿は ワールドワイドで金融業界を担当している プリンシパルソリューションアーキテクト の Ilya Epshteyn による寄稿を翻訳したものです。 グローバル展開されている金融事業グループの中でプリンシパルソリューションアーキテクトとして、私が最もよく聞かれる質問の1つは、特定の AWS サービスが 金融サービスで利用可能かどうかです。金融サービスのような規制された業界では、クラウドへの移行は単純なリフト＆シフト作業ではありません。代わりに、金融機関は、 一般的にホワイトリストと呼ばれる秩序だったサービスごとの評価プロセスを使用して、クラウドサービスが規制上の義務にどのように対応できるかを実証しています。このプロセスが明確に定義されていない場合、クラウドにデータを移行
BeyondCorp? ゼロトラスト？ VPNを超えていけ！ - ブログなんだよもん
TL;DR はじめに BeyondCorp << ゼロトラスト ゼロトラストセキュリティ リモート接続のセキュリティ3要素 Authentication/認証 Device Trust/機器認証 Encryption/暗号化 VPNの問題点 キャパシティ/パフォーマンス 適切な制御の難しさ 一貫したセキュリティポリシーの適用が困難 ゼロトラストによるセキュアな通信 ゼロトラストの企業ネットワーク コンテキスト認識アクセスコントロール ゼロトラストによるVPNの問題点の解決 ゼロトラストの課題と展望 まとめ 参考 TL;DR BeyondCorpはゼロトラストの実装の一つ。ゼロトラストは超乱暴に言えばポストVPN 社内も信用出来ないとして社外と同じ方式でNWを組む HTTPSによる暗号化と次世代認証基盤を使ったCAACによるアクセスコントロール FWによる境界からIDによる境界へのパラダイム
Coinbaseがうけた標的型攻撃とその対応についてまとめてみた - piyolog
暗号資産を取り扱う米国のCoinBaseは、2019年6月に発生したFirefoxの脆弱性（当時ゼロデイ）を悪用した攻撃への対応を2019年8月9日にセキュリティ担当者がBlogで明らかにしました。ここでは一連の対応の顛末についてまとめます。 対応公開までの経緯 情報の公開を行ったのは米暗号資産取扱い事業者 Coinbaseのセキュリティ担当者 Philip Maritin氏。 2019年6月20日にTwitterで第一報レベルの情報共有が行われていた。 1/ A little more context on the Firefox 0-day reports. On Monday, Coinbase detected & blocked an attempt by an attacker to leverage the reported 0-day, along with a separ
どうして JWT をセッションに使っちゃうわけ？ - co3k.org
備考 2018/09/21 22:15 追記 2018/09/20 12:10 に公開した「どうして JWT をセッションに使っちゃうわけ？」というタイトルが不適切だとご指摘をいただいています。 その意見はもっともだと思いますので、現在、適切となるようにタイトルを調整しています。 ご迷惑およびお騒がせをして大変申し訳ございません。 本文の表現についても改善の余地は大いにありそうですが、こちらは (すでにご意見を頂戴している関係で、) 主張が変わってしまわないように配慮しつつ慎重に調整させていただくかもしれません。 はあああ〜〜〜〜頼むからこちらも忙しいのでこんなエントリを書かせないでほしい (挨拶)。もしくは僕を暇にしてこういうエントリを書かせるためのプログラマーを募集しています (挨拶)。 JWT (JSON Web Token; RFC 7519) を充分なリスクの見積もりをせずセッシ
バグハンターのためのクライアントサイドJavaScriptの静的解析 - No1zy Web Security Blog
はじめに JavaScriptは、最新のWebブラウザで最も普及した技術の1つになっています。AngularJS、ReactJS、Vue.jsなどのクライアントサイドJavaScriptフレームワークを使用して構築されたアプリケーションは、多くの機能とロジックをフロントエンドに提供します。そしてロジック、機能の増加によってクライアントサイドのAttack Safaceも増加します。これらのAttack Safaceを理解し、脆弱性を発見する方法を身に着けることが必要です。 このブログ記事では、効率よくWebアプリケーションの脆弱性を発見するために、クライアントサイドJavaScriptの静的解析に注目して説明します。 今回は脆弱性を探す対象はOWASP Juice Shopです。Juice ShopはJavaScript製の意図的に脆弱に作られたアプリケーションです。 何を探すか? セキュ
認証にまつわるセキュリティの新常識 - Speaker Deck
2016-2017年でのNIST SP800-63-3改定を通じて、認証を含むデジタルアイデンティティの世界では様々な議論が湧き起こりました。 そんな本ガイドラインの内容を通じて、デジタルアイデンティティフレームワークを考える上での共通言語、特に「認証方法」について記載したNIST SP800-63Bについての理解と体得を試みつつ、議論になったいくつかのテーマについて取り上げて、この領域の面白さに触れてみます。 [rev3] 2022年1月までのアップデートを追加して、個別依頼を受けて実施したプライベートセミナー向けの版をサニタイズしてアップロードしました。〆切ドリブンで改定機会をくださった会社様には感謝です。 主な改定 ・SMSへの攻撃としてSS7とSakari/Bandwidth社の事例 ・よくある追加認証のトピックス ・アカウントリカバリの文言改善（解釈文書を元に） ・NIST SP
Pod Security Policies
Removed featurePodSecurityPolicy was deprecated in Kubernetes v1.21, and removed from Kubernetes in v1.25. Instead of using PodSecurityPolicy, you can enforce similar restrictions on Pods using either or both: Pod Security Admissiona 3rd party admission plugin, that you deploy and configure yourselfFor a migration guide, see Migrate from PodSecurityPolicy to the Built-In PodSecurity Admission Cont
2018/07/12 に発生したセキュリティ インシデント (eslint-scope@3.7.2) について - Qiita
2018 年 7 月 12 日に、ESLint 開発チームが管理する npm パッケージに悪意あるコードが挿入されるセキュリティ インシデントがありました。 ESLint からのアナウンス: https://eslint.org/blog/2018/07/postmortem-for-malicious-package-publishes npm からのアナウンス: https://status.npmjs.org/incidents/dn7c1fgrr7ng 以下の場合に npm install を実行したユーザーの npm アカウントへのログイン情報 (アクセストークン) が盗まれた恐れがあります (盗まれたアクセストークンはすでに無効化されています)。 日本時間の 18:49 から 19:25 の約 1 時間のあいだに npm install を実行し、eslint-config-e
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く
FISCから学ぶAWSセキュリティことはじめ.pdf
