AWSを不正利用された際の反省と教訓 - Qiita
反省 被害 AWSのSESを利用され、約5万通のメールが不正に送信され、約10ドルの使用料が発生しました。また、焦ってルート権限のMFA設定時にアプリ（別のアプリ用の番号を選択し続ける）の選択を誤り、余計に焦ることになりました。 頭によぎった過去の悪夢 症状 DKIM設定成功通知: 不審なDKIM設定完了の通知を受け取りました（9月12日７時ごろ） 料金アラート: AWSからSESの使用料金が閾値に達したアラートが送信されました（9月13日9時ごろ） 不正なメール送信: 数万通の不正メールが送信され、料金が急増しました ドメインの登録と削除: 知らないドメインがAWSに登録されていました。至急登録されていたドメインを削除しました(9月13日11時ごろ） IAMユーザーでのログイン失敗: 一旦削除したのでホッとした１時間後、IAMユーザー権限でのログインができなくなり、焦りが増しました（9月
AmazonのAI「Amazon Q」は重度の幻覚によってAWSデータセンターの場所などの機密データを漏えいしているとの指摘
2023年11月29日に発表されたばかりのAIチャットサービス「Amazon Q」にプライバシーの問題がある可能性が報じられました。一部の従業員によるとAmazon Qはひどい幻覚(ハルシネーション)に襲われることがあり、Amazon Web Services(AWS)のデータセンターの場所などを漏らすことがあるそうです。 Amazon’s Q has ‘severe hallucinations’ and leaks confidential data in public preview, employees warn https://www.platformer.news/p/amazons-q-has-severe-hallucinations Amazon's AI Chatbot, Amazon Q, Faces Criticism and Security Concerns h
Log4j 脆弱性を緩和するAWS WAFの「Log4JRCE」DevelopersIOサイトの3日間の検出結果を紹介します | DevelopersIO
IPアドレスは、ELB (国内向)、Global Accelerator(海外向) のIPアドレスで利用中のものでした。 $ host 75.2.71.201 201.71.2.75.in-addr.arpa domain name pointer a5b041b48e73d3807.awsglobalaccelerator.com. $ host 52.194.15.214 214.15.194.52.in-addr.arpa domain name pointer ec2-52-194-15-214.ap-northeast-1.compute.amazonaws.com. $ host dev.classmethod.jp dev.classmethod.jp has address 75.2.71.201 dev.classmethod.jp has address 99.83.1
AWS環境にセキュアなベースラインを提供するテンプレート「Baseline Environment on AWS」のご紹介 | Amazon Web Services
Amazon Web Services ブログ AWS環境にセキュアなベースラインを提供するテンプレート「Baseline Environment on AWS」のご紹介 みなさんこんにちは。ソリューションアーキテクトの大村です。 このブログでは、私たちAWS Japanのソリューションアーキテクトが AWS Samples に公開している 「Baseline Environment on AWS（BLEA）」について詳しくご紹介します。 これはAWSのセキュリティのベストプラクティスを実装した環境を、迅速に実現するためのテンプレートです。 セキュリティサービスだけでなく、よく利用されるアプリケーションの実装サンプルも含んでいます。これによって基本的なセキュリティを実現した状態をスタート地点としてシステム構築を開始できます。このテンプレートは単一のアカウントでも、また AWS Contro
踏み台EC2を廃止してSession Manager接続に置き換えました
こんにちは、エウレカ SRE チームの原田です。 今年 (2021年) エウレカでは、公開鍵認証で接続するEC2の踏み台サーバを廃止し、代わりに各サーバへの接続をIAMで認証できるSSM Session Managerへのリプレースを行いました。本記事ではそのモチベーションや、実装のポイントを紹介していきたいと思います。 旧来の踏み台サーバ 旧来の踏み台サーバエウレカで長く運用されていた踏み台サーバ (Gateway) は以下のようなものでした。 各開発者は、自分の秘密鍵を使って踏み台サーバへSSHを行う ( 踏み台サーバ上には各開発者の個別ユーザーおよび公開鍵が登録されている )踏み台上では、接続が許可されているSSH対象のサーバの秘密鍵がユーザー毎に配置されており、その鍵で各サーバにSSHするMySQL / Elasticsearch / Redis など、Private Subnet
【実録】攻撃者のお気に入り API 10選 | DevelopersIO
AWSアクセスキーセキュリティ意識向上委員会って何？ 昨今、AWSのアクセスキーを漏洩させてしまうことが原因でアカウントへの侵入を受け、 多額の利用費発生・情報漏洩疑いなど重大なセキュリティ事案が発生するケースが実際に多々起きています。 そこで、アクセスキー運用に関する安全向上の取組みをブログでご紹介する企画をはじめました。 アクセスキーを利用する場合は利用する上でのリスクを正しく理解し、 セキュリティ対策を事前に適用した上で適切にご利用ください。 はじめに 弊社オペレーションチームでは、AWS よりお客様アカウントの侵害疑いの連絡を受けた際に、状況確認のため CloudTrail を調査しています。本記事では調査で気づいたことをいくつかお伝えできればと思います。 仮想通貨のマイニングを例とすると、攻撃者は自分たちの IAM ユーザーを作り、とにかく「ハイスペックなインスタンス」をとにかく
[AWS利用者必読] アクセスキー漏洩による不正利用について | DevelopersIO
AWSアクセスキーセキュリティ意識向上委員会って何？ 昨今、AWSのアクセスキーを漏洩させてしまうことが原因でアカウントへの侵入を受け、 多額の利用費発生・情報漏洩疑いなど重大なセキュリティ事案が発生するケースが実際に多々起きています。 そこで、アクセスキー運用に関する安全向上の取組みをブログでご紹介する企画をはじめました。 アクセスキーを利用する場合は利用する上でのリスクを正しく理解し、 セキュリティ対策を事前に適用した上で適切にご利用ください。 【はじめに】 昨今､アクセスキーの漏洩を契機とした不正利用の発生が多発しております｡AWS 利用のお客様へのビジネスリスクが非常に大きく､弊社としても憂慮する状況です｡ そのため､以下をお読み頂き AWS 利用のお客様は環境の見直しをお願い致します｡ 【この記事で伝えたいこと】 多額の費用発生リスクをなくすために､可能な限りアクセスキーの利用を
[2020年版]最強のAWS環境セキュリティチェック方法を考えてみた[初心者から上級者まで活用できる] | DevelopersIO
「AWS環境のセキュリティが不安だ…」そんな方にはセキュリティチェック！AWSでは定量的にチェックすることができる機能があります。いくつかあるので長短などを説明しつつ私が思う最強のセキュリティチェックを伝授します！ こんにちは、臼田です。 みなさん、AWS環境のセキュリティチェックしてますか？(挨拶 全国のAWSのセキュリティについて悩んでいるみなさまのために、今回は僕の考える最強のAWS環境セキュリティチェックについて情報をまとめ・伝授します。 初心者向けに、比較的AWSの経験が浅くても始めやすいように、かつ上級者が応用するために活用できる情報もぜんぶまとめていきます。 この記事は2020年の決定版となるでしょう！(それ いいすぎ。 ながーくなってしまったので最初は適宜飛ばして読むといいかもしれません。 AWS環境のセキュリティチェックの意義 AWS環境でセキュリティチェックをすることは
![[2020年版]最強のAWS環境セキュリティチェック方法を考えてみた[初心者から上級者まで活用できる] | DevelopersIO](https://cdn-ak-scissors.b.st-hatena.com/image/square/46eee47df02797b1711e39b4cf67a6a7b8f87e53/height=288;version=1;width=512/https%3A%2F%2Fdevio2023-media.developers.io%2Fwp-content%2Fuploads%2F2020%2F10%2Fsuper_security_check_1200_630.png)
flaws.cloudでAWS環境にSSRF攻撃をやってみた Level 1 - chikoblog
※この記事はflaws.cloudのやり方が載ってます。今後flaws.cloudにチャレンジ予定の方はネタバレになってしまいます。 EC2インスタンスメタデータサービスv2のリリースでも上がっている flaws.cloudを使ってSSRF攻撃について個人的に調査してまとめてみました！ 以下参考記事 クラメソ様のEC2インスタンスメタデータサービスv2のリリースの記事 dev.classmethod.jp SSRF攻撃についてpiyokango様がまとめている記事 piyolog.hatenadiary.jp そもそもSSRF攻撃って？ SSRF攻撃をすごく簡単に説明すると 通常のWEBサイトとかのイメージだとWEBにアクセスしてくるユーザは WEBサーバやその他外部公開用のサーバにアクセスしてWEBのページを見ることが可能です。 SSRFの脆弱性がある場合、 攻撃者は公開サーバ(WEBと
AWSセキュリティベストプラクティスを実践するに当たって適度に抜粋しながら解説・補足した内容を共有します | DevelopersIO
こんにちは、臼田です。 皆さん、セキュリティ意識してますか？(挨拶 今回はお客様宛にAWSのセキュリティベストプラクティスについて補足・解説したものを汎用化して共有します。 公式のドキュメントだと少し硬くて読みづらいみたいなイメージもあるかと思いますので、こちらの記事を参考に感覚を掴んでいただければと思います。なお、いろいろ簡潔にしたりするためにすべてのことについて説明していませんのでご了承ください。 熟読いただきたい資料 AWSのセキュリティベストプラクティスの資料は本当は熟読していただきたいです。しかしながら、最初はとっつき辛いと思うのでこの先の内容を見ていただいて、余力があればこちらのセキュリティベストプラクティスを見ていってください。 https://d1.awsstatic.com/whitepapers/ja_JP/Security/AWS_Security_Best_Prac
脆弱なAWS S3侵害によるユニクロオーストラリアの入力フォーム改ざんについてまとめてみた - piyolog
Netcraftは、2019年5月13日頃にユニクロのオーストラリア向けオンラインショップが改ざんされ、画面上で入力する様々な情報が外部へ流出する可能性があったと報告しました。データの送信先や改ざんの手口から、RiskIQなども発表していたmagecartによる攻撃を受けたとみられます。 その後レポートは更新され、ファーストリテイリングより提供を受けた情報を元に、実際にはカード情報を含む顧客データが盗まれた可能性は低いと訂正されました。ここでは関連する情報をまとめます。 ユニクロオーストラリアの侵害 2019年8月29日、Netcraftが調査レポートを公開した。 news.netcraft.com Netcraftが事態を認知したのは2019年5月18日。 オンラインショップ利用者の情報が影響を受ける可能性があった。 発表当初はカード情報が必ず窃取される報告だったが、その後その可能性は低
AWSのMFAの仕組みを実装して読み解いてみた | DevelopersIO
最近認証や認可の話題が度々でていますね。 ふとAWSのMFAはどのような実装になっているか気になったので調べて実装してみました。 MFAについて MFAの設定は済んでますか。もしまだの方や、うろ覚えの方がいましたらこちらの記事を先に見て設定することをお勧めします。 IAMユーザーのMFA（多要素認証）は有効になっていますか？現状を確認→是正→適切な状態を維持するまでの流れを整理してみた MFAの設定が終わったところで、本題に入っていきましょう。 AWSの多要素認証のページを見るとこんなことが書いてあります。 オープン TOTP スタンダードをサポートするアプリケーションを実行するスマートフォンやタブレットをご使用ください。 https://aws.amazon.com/jp/iam/details/mfa/ オープン TOTP スタンダードは何かわからないですが、私たちは、MFAのためにA
AWSを使うときに確認すべき52のセキュリティチェック項目と15分でできる簡単なチェックの方法｜DevelopersIO
はじめに 自分が使っているAWS環境のセキュリティに問題がないかと心配になることはないでしょうか？私はよくあります。そこでCIS Amazon Web Service Foundations Benchmark というAWSのセキュリティのガイドラインに沿って使っているAWSアカウントのセキュリティの状況をチェックしてみました。チェック項目は全部で52あります。内容を一通り確認したところ知らなかったAWSのセキュリティの機能やノウハウを知ることができ、見ただけでもとても勉強になりました。簡単にチェックする方法も併せて紹介しますのでぜひ使っているAWS環境でチェックしてみてください。 1 IAM 1.1 rootアカウントを利用しない rootアカウントは強力な権限を持つため、rootアカウントを利用せずIAMユーザーを利用してください。通常運用でrootアカウントが利用されていないか確認し
AWSから120万円の高額請求が来た話
筆者は2018年の夏にAWSから高額請求を受けました。 とある開発合宿の夜、LaravelでS3に画像をあげ、CroudFront経由で表示させるための実装を行っていた時の出来事です。 AWSのコンソール画面とにらめっこしていた時に、ふと左サイドバーの履歴の項目に、気になる項目が目に付きました。 ん？ 請求？ 普段はこんな項目出て来ないため、気になったのでクリックしてみました。その瞬間、恐ろしい現実を目の当たりにしたのです。 請求を押した時に開かれた画面が、以下の通りでした。 【請求画面の画像】 及び10000$！日本円にして、約124万円の請求が来ていました。 何かの間違えだと思ったが、少し怖くなったのでひとまず、こういった事例がなぜ起こるのか、自分に当てはまる原因がないかを調べるため、「AWS 高額請求」などでググってみました。 すると、いくつか記事が早速上位にヒットしました。 htt
運用担当者のためのAWS改善マップ | DevelopersIO
Trusted Advisor AWS Trusted Advisorは、コスト、パフォーマンス、セキュリティ、耐障害性、サービスの制限について、アドバイスしてくれるサービスです。 サポートプランによって、チェック項目が異なります。 セキュリティについては、セキュリティグループの無制限アクセス、S3バケット許可などをチェックしてくれます。 セキュリティについては、赤の指摘項目は0にしましょう。 insightwatch insightwatchは、弊社が提供するサービスです。 AWSアカウントが、ガイドラインに沿ったセキュリティのベストプラクティスで運用されているかチェックします。 複数アカウントをチェックしやすいため、たくさんのアカウントを運用されているかたに特にお勧めします。 どなたでも無料でご利用いただけます。 IAMの見直し、定義 IAM のベストプラクティスに基づいた見直しを行い
AWS を安全に使うために（IAM のベストプラクティス） | DevelopersIO
セキュリティインシデントを止めるには IAM から。IAM の正しい使い方を一度覚えればセキュリティリスクは低減できます。AWS のドキュメント「IAM のベストプラクティス」をできるだけ具体的に解説してみましたのでご一読ください。 はじめに AWS を利用するにあたり、セキュリティをいかに確保するかが最優先事項となります。 今回は AWS を利用する際に一番最初に設定するであろう IAM で必要な設定について、AWS が推奨しているベストプラクティスに添って可能な限り分かり易く説明していきます。 IAM とは AWS の操作をより安全に行うため、AWS リソースへのアクセスを制御するためのサービスです。 IAM により、複数のユーザーに AWS リソースへの安全なアクセスを簡単に提供できます。 とある会社の場合 例として以下のような会社を定義します。 社長 x 1人 部長 x 2人（営業
Amazon S3バケットのアクセス設定に関する注意喚起メールにつきまして | Amazon Web Services
Amazon Web Services ブログ Amazon S3バケットのアクセス設定に関する注意喚起メールにつきまして 2017年7月19日前後より、Amazon Web Services(AWS)の一部のお客様に対し、“Securing Amazon S3 Buckets” という件名のメールをご送付させていただきました。Amazon S3 のバケットポリシーやアクセスコントロールリスト(ACL)の設定の不備によって、Amazon S3 上の重要なデータが漏洩するセキュリティリスクに対する注意喚起となります。Amazon S3 のバケットポリシーや ACLの設定について、この注意喚起メールを必要な設定の見直しのきっかけにしていただければと思います。なお、メールを受け取られたお客様に、必ずしも問題があることを示すものではありません。 メールが送られた契機について 重要なデータが漏洩した
AWSアクセスキーをGitリポジトリに混入させないために git-secrets を導入した | DevelopersIO
先日開催されたAWS Summit Tokyo 2017、わたしもいくつかセッションを聴講してきたのですが、「DevSecOps on AWS - Policy in Code」というセッション1にてgit-secretsというツールが紹介されていました。 awslabs/git-secrets: Prevents you from committing secrets and credentials into git repositories これ以外にも、いくつかのセッションで言及されていたと思います。 git-secretsのことは以前から聞いてはいたのですが、自分自身があまりコードを書く環境にいなかったので、良くないとは思いつつも今まであまり気にしていませんでした。 ただ、AWSアクセスキーの漏洩が原因と思われる話を聞く機会はなかなか減りませんし、考えてみれば自分でも、AWSクレデ
AWSが不正利用され300万円の請求が届いてから免除までの一部始終 - Qiita
前置き 情けないことだが、自身の過失により、GitHubで長年Privateリポジトリで運用していたリポジトリを、とある事情でpublicに変更したのだが、その中にAWSのS3のアクセスキーとシークレットキーがファイルに直接ハードコーディングされているのにすっかり気づかず、自身のAWSのアクセスキーとシークレットキーが流出してしまうという失態を起こしてしまった。 その不正利用により届いた請求金額は約300万円。請求を見た時は頭が真っ白になり冷や汗ものだったが、過去に同様のミスとその状況と対応をまとめてくださっていた方々のおかげで、なんとか深呼吸して対応することができたので、自分も少しでも今後起きうる同様の状況の方に対する助けになればと、一部始終を共有しておくことにしようと思う。 初心者がAWSでミスって不正利用されて$6,000請求、泣きそうになったお話。 AWS で不正アクセスされて凄い
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く
なるべく楽したいAWSセキュリティ
