最小限で基礎的なセキュリティガイダンスである「AWS Startup Security Baseline (AWS SSB)」を紹介します | DevelopersIO
最小限で基礎的なセキュリティガイダンスである「AWS Startup Security Baseline (AWS SSB)」を紹介します いわさです。 SaaS on AWS では大きく 4 つのフェーズ（設計・構築・ローンチ・最適化）で役立てる事ができるコンテンツが提供されています。 設計フェーズでは技術面からコンプライアンスに準拠したりセキュリティベースラインを考える必要があります。 これらについてベストプラクティスが提案されている動画コンテンツがあります。 その中で初期段階で実施出来ることとして次のステップが紹介されていました。 セキュリティ周りは Well-Architected Framework や Security Hub の適用から始めることも多いと思いますが、様々な制約からすぐの導入が難しい場合もあります。 そんな方に本日は上記の中の AWS Startup Secur
【総まとめ】GuardDutyによるコンテナランタイム脅威検知の注意事項と設定手順と検出の様子 #AWSreInvent | DevelopersIO
AWSマネージドサービスGuardDutyによる待望のコンテナランタイム脅威検知。その検知内容と設定上の注意事項、検出の様子をまとめてお届けします。 「ECSのランタイム脅威検知って、商用製品必須だよね。どれにすっかなぁ。結構高いよね」 「1年前の予告を経て、よーーーやくAWSマネージドなやつがGAされましたよ」 去年のre:Invent2022においてKeynote中に予告だけされていたコンテナ環境のランタイム検知（【速報】GuardDutyによるコンテナランタイムの脅威検知サービスが発表されました！）。 先日のre:Invent 2023のアップデートにより、待望のECSにおけるランタイム検知が、GuardDutyで実現できるようになりました！！もともとEKSにおけるランタイム検知は提供されていましたが、それがECSにも拡張されたアップデートです。 これまでAWSのECSにおいてランタ
[DevSecOps] コンテナ時代のアンチウィルス対策はどうすればいいのか調べてみた｜Anno Takahiro
エンタープライズ企業が新しいクラウドサービスを導入する時には、自社のセキュリティ基準を満たせていることを確認するのが通例である。「セキュリティチェックシート」と呼ばれるエクセルシートを利用して一点一点チェックしていくことが多い。（この質問票で聞かれる内容が個社ごとにばらばらで、システム導入時に双方の負担になってしまっているのを標準化してなんとかできないかと思うことはあるが、この記事ではそこには触れない。） よくあるのが、「アンチウィルスソフトウェアをサーバーにインストールしていること」というチェック項目だ。明快な質問のように見えるが具体で実現するためには色々考えなければいけないことがある。標準的なサーバー構成、つまり、ハードウェアがあって、その中でOSが稼働していて、その上でアプリケーションが動いているというシンプルな構成であれば良いのだが、クラウドインフラを使い倒すようになった今ではマイ
![[DevSecOps] コンテナ時代のアンチウィルス対策はどうすればいいのか調べてみた｜Anno Takahiro](https://cdn-ak-scissors.b.st-hatena.com/image/square/d40f582c13ec7b50a24702f677080474932e9b61/height=288;version=1;width=512/https%3A%2F%2Fassets.st-note.com%2Fproduction%2Fuploads%2Fimages%2F24412229%2Frectangle_large_type_2_8c36b95904fe1cfb50326f80f7e5b1fb.jpeg%3Ffit%3Dbounds%26quality%3D85%26width%3D1280)
Your API Shouldn't Redirect HTTP to HTTPS
TL;DR: Instead of redirecting API calls from HTTP to HTTPS, make the failure visible. Either disable the HTTP interface altogether, or return a clear HTTP error response and revoke API keys sent over the unencrypted connection. Unfortunately, many well-known API providers don't currently do so. Updates 2024-05-24: Added the Google Bug Hunter Team response to the report that the VirusTotal API resp
SameSite属性とCSRFとHSTS - Cookieの基礎知識からブラウザごとのエッジケースまでおさらいする - Flatt Security Blog
こんにちは、 @okazu_dm です。 この記事は、CookieのSameSite属性についての解説と、その中でも例外的な挙動についての解説記事です。 サードパーティCookieやCSRF対策の文脈でCookieのSameSite属性に関してはご存知の方も多いと思います。本記事でCookieの基礎から最近のブラウザ上でのSameSite属性の扱いについて触れつつ、最終的にHSTS(HTTP Strict Transport Security)のような注意点を含めて振り返るのに役立てていただければと思います。 前提条件 Cookieについて Cookieの属性について SameSite属性について SameSite属性に関する落とし穴 SameSite属性を指定しなかった場合の挙動 SameSite: Strictでも攻撃が成功するケース 例1: スキームだけ違うケース 例2: サブドメイ
セキュアなトークンの作り方 - astamuse Lab
開発部のにゃんです。主にバックエンドを弄っております。 Webアプリケーションではセキュリティ対策のためにランダムな文字列を使用する場面が多々あります。例えば CSRF対策のトークン OAuthやOpenID Connectで使用するnonce, state, code_verifier メールの到達確認用URLのトークン パスワードをhashする際に使用するsalt セッションID これらの値は単に衝突しなければOKというものではありません。十分なセキュリティ強度を確保するためには推測不可能なランダム値を使う必要があります。 以下は推測不可能なランダム値ではありません。セキュリティが求められる場面では使ってはいけません。 Math.randomなどの疑似乱数 日付やユーザ情報のハッシュ ではどのような値が適切なのでしょうか？ /dev/randomと/dev/urandom Linuxに
ストレッチングの回数を自動制御することに意味はあるのか考えてみた。 - piyolog
ストレッチングは必要なのか 皆さんは「ストレッチング」という手法をご存知でしょうか。 以前からたびたびTwitter上で「ストレッチングは行う必要があるのか」という議論が交わされています。 最近では太田さんが自身の開発体験を踏まえ、ストレッチングのエントリをされています。 ストレッチング採用の理由−水無月ばけらのえび日記 徳丸本のあれこれを実践してみて気付いたこと−水無月ばけらのえび日記 また、北河さんや徳丸さんはストレッチングの必要性に関して次のようなつぶやきをされています。(これだけでは断片的なのでできれば前後の内容も参照してください。) http://twitter.com/kitagawa_takuji/status/61258646180470784:twitter:detail:left http://twitter.com/ockeghem/status/7510281023
SSHの公開鍵認証における良くある誤解の話 - Qiita
Deleted articles cannot be recovered. Draft of this article would be also deleted. Are you sure you want to delete this article? はじめに 背景 これを知っていたからと言って何かの役に立つかというと、そうでない人の方が多いとは思うのですが、いい加減、SSHの公開鍵認証の説明がデマばかりなので、少しはちゃんとした説明もあった方が良いかもな、ということで記事にしました。 SSHについて 皆さんご存知の通り、SSHはSecureSHellの略であり、暗号によって保護された通信を通じて遠隔操作を行う1アプリケーション、またはプロトコル2を指します。 Linux等のUNIX系OSの遠隔操作3、またはネットワーク機器の管理に広く使われており、その実装としてはOpenSSHが有
ユーザーをログアウトから守れ！―シーケンス図から読み解くログイン状態維持【Webアプリ編】 | DevelopersIO
認証というのは面倒なもので、利用者に余計な手間を掛けさせてアクティブ率を下げたくないと日夜工夫を凝らす我々にとっては、やり玉に上がりやすいテーマであると思います。要するに、ユーザーをログアウトさせたくないわけです。さて、どうしましょう？ 生魚おじさん、都元です。今月の魚はアジです！アジを食べましょう。 さて、認証というのは面倒なもので、利用者に余計な手間を掛けさせてアクティブ率を下げたくないと日夜工夫を凝らす我々にとっては、やり玉に上がりやすいテーマであると思います。要するに、ユーザーをログアウトさせたくないわけです。 例えば Facebook や Twitter のページはいつ訪問しても自分のアカウントでログイン状態になっています。 最後にログインしたのはいつでしたっけ？ 覚えていませんよね？ これがおそらく皆さんの理想です。 セッションによるログイン ログインには通常、Cookie を
Spring Security にできること・できないこと - Qiita
自己紹介 opengl-8080 主に Qiita で技術メモを書いたり 関西の SIer 勤務 今日お話しすること Spring Security が保護してくれること、してくれないこと Spring Security を導入すれば、この攻撃は守ってくれる この攻撃は Spring Security の守備範囲外なので別途対処が必要 仕様や機能の話をメインにして、実装の細かい話は無し デモ用アプリ 起動方法 GitHub からプロジェクトをダウンロードし、プロジェクトのルートで gradlew start を実行 ※初回は Payara （60MB）などのダウンロードが行われるので注意 動作確認 AP サーバーが起動したら、以下の URL にアクセスする。 https://localhost:8443/secure Spring Security を使用したアプリケーション https:
例えば、Strutsを避ける
はじめに 筆者は10年以上ウェブアプリケーション開発を主な業務とするJavaプログラマであったにも関わらず、Strutsについてはこれまでずっと食わず嫌いでした。初期のStrutsは「XMLだらけで効率が悪そう」というイメージが強かったためです。最近はRuby on Rails等の影響を受けCoC(convention over configuration)を採り入れ、XML地獄もだいぶ解消したようです。 StrutsはJavaアプリケーションらしくない種類（任意のコード実行等）の脆弱性を連発することでも知られており、最近は我々の提供するSaaS型WAFサービス、Scutum(スキュータム)のお客様からも頻繁にStrutsについての問い合わせを受けるようになりました。また、去年見つかった任意のコード実行の脆弱性では、脆弱性の公表後すぐにPoCが出回り実際に攻撃が発生するなど、悪い意味で注目
1
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く
PenTesterが知っている危ないAWS環境の共通点
AWS固有のセキュリティリスクと対策 - Speaker Deck