フリーWi-Fiを使ったら秘密情報を抜かれる経路にはどのようなものがあるか - Qiita
ゴールデンウィークのはじめ（4月29日）に投稿された以下のツイートですが、5月7日20時において、1,938.8万件の表示ということで、非常に注目されていることが分かります。 我が名はアシタカ！スタバのFreeWi-Fiを使いながら会社の機密情報を扱う仕事をしてたら全部抜かれた。どうすればよい！ pic.twitter.com/e26L1Bj32Z — スタバでMacを開くエンジニア (@MacopeninSUTABA) April 29, 2023 これに対して、私は以下のようにツイートしましたが、 これ入社試験の問題にしようかな。『スタバのFreeWi-Fiを使いながら会社の機密情報を扱う仕事をしてたら全部抜かれた』と言う事象に至る現実的にありえる脅威を説明せよ。結構難しいと思いますよ。 https://t.co/LH21zphCTV — 徳丸 浩 (@ockeghem) April
正規表現の脆弱性 (ReDoS) を JavaScript で学ぶ
先日、このようなツイートを書いたところ、かなりの反響がありました。 JavaScript の正規表現の脆弱性の例でいうと、例えば /\s+$/ は脆弱性があると言える console.time(); /\s+$/.test(" ".repeat(65536) + "a"); console.timeEnd(); 結構時間がかかるのがわかる。でも /\s+$/ を見て「これは危険だな」と理解出来る人はそんなにいない。JavaScript に限らないけれど。 — Takuo Kihira (@tkihira) February 17, 2022 これは一般に ReDoS (Regular expression Denial of Service) と呼ばれる脆弱性です。正確に理解するのが難しい脆弱性なので、少し解説してみたいと思います。 結論 長い記事になるので、最初に「とりあえずこれだけ知っ
ゼロからはじめる実践 Kubernetes セキュリティ(1) Kubernetesのセキュリティ対策の第一歩とは？
本連載では、エンタープライズシステムでコンテナ／Kubernetesを活用した業務システムを開発・運用するエンジニアに向けて、知っておくべきKubernetesセキュリティの基礎知識、Microsoftが提供するパブリッククラウド「Azure」を使ったクラウドにおけるKubernetesのセキュリティ対策のポイントや注意点といった実践的なノウハウを紹介します。 コンテナ／Kubernetes環境に求められるセキュリティとは？ 今日、オンプレミスの環境で運用されていた業務システムの多くが、クラウドへの移行を進めています。クラウドを活用することで、高い拡張性を持つセキュアなシステムを短期間で開発できます。加えて、コンテナベースのクラウドネイティブ・アプリケーションにモダナイズすることで、変化の激しいビジネス環境に追随できるだけでなく、最新技術を起点としてこれまでになかったビジネスモデルを構築し
マイクロサービスの認証・認可とJWT / Authentication and Authorization in Microservices and JWT
OCHaCafe Season4 #4の資料です． デモのソースコード等はこちらをご参照ください．
DevSecOpsとは何か — 導入する組織が増加している理由 | メルカリエンジニアリング
Mercari Advent Calendar 2020 の15日目は、メルカリ Product Security チームの Gloria Chow がお送りします。 こんにちは、Product Securityチームの@gloriaです。以前、オープンソースとして公開しているTestdeckという、マイクロサービスの自動化テストのための社内ツールについて記事を書きました。 今回は、2020年のAdvent Calendarの記事として、DevSecOpsについてお話をしたいと思います。近年、耳にする機会の多い話題の一つなので既にご存じの方もいらっしゃるかもしれませんが、DevSecOpsの基本的なコンセプト、注目されている理由、よくあるチャレンジとメルカリにおけるDevSecOpsの実践事例を紹介したいと思います。 DevSecOpsとは? DevSecOps以前から提唱されているDev
AWSアカウントを作ったら最初にやるべきこと ～令和元年版～ | DevelopersIO
はじめに 中山（順）です 4年ほど前にこの記事のタイトルと同じテーマで資料を作成したことがあるのですが、古い内容があったり新しいサービスのことが含まれていなかったりするので改めてまとめてみました。令和だし！ その時の資料はこちらです（クラスメソッドにジョインするくらい2年前です）。 AWSアカウントを作ったら最初にやるべきこと サインアップ （業務利用の場合）非個人メールアドレスでサインアップ サポートプランの確認 ID管理 / 権限管理 CloudTrailの有効化 ルートアカウントのMFA設定 IAM User / IAM Groupの作成 パスワードポリシーの設定 GuardDutyの有効化 Security Hubの有効化 請求 IAM Userによる請求情報へのアクセス許可 支払通貨の変更 Budgetの設定 Cost Explorerの有効化 Cost Usage Report
Rust言語のメリットと課題、「Azure IoT Edge」の事例から分かること
Microsoft Security Response Center（MSRC）は2019年9月30日（米国時間）、Microsoft社内におけるRust言語の採用事例を発表した。 「Azure IoT Edge」のセキュリティデーモンコンポーネントを実装するプログラミング言語として「Rust」を選択した背景と、実装過程で分かったメリットと課題が分かる。 Azure IoT Edgeは、MicrosoftのAzure IoTチームが手掛けるオープンソースのクロスプラットフォームソフトウェアプロジェクト。プロジェクトの目的は、クラウドからオンプレミスネットワーク内のエッジへとコンピューティング機能の分散を進め、管理する上での問題解決だ。 Azure IoT Edgeのセキュリティデーモンは、Azure IoT Edgeランタイムを起動（ブートストラップ）する。さらに、Azure IoTランタ
「Docker Hub」ポータル、著名コンテナの20％に設定ミス
印刷する メールで送る テキスト HTML 電子書籍 PDF ダウンロード テキスト 電子書籍 PDF クリップした記事をMyページから読むことができます Kenna Securityは米国時間5月20日、「Docker Hub」上で広く利用されている1000の「Docker」コンテナのうち、およそ20％がある種の条件下でユーザーシステムに対する攻撃を許す設定になっていることを明らかにした。 これは、Cisco Talosが8日に明らかにした、公式版の「Alpine Linux Docker」コンテナに存在する脆弱性と同じ問題と言える。Alpine Linux Dockerイメージは過去3年間にわたり、パスワードを空白にした管理者アカウントが有効な状態でリリースされていた。 Kenna Securityの主席セキュリティエンジニアであるJerry Gamblin氏は、Docker Hub上
Dockerでマストドンやってたら、遮断したはずのポートが丸見えだった件 | Divide et impera
みんなマストドンをやっているだろうか？ 僕はやっている。 インスタンス管理をやっている。 こんなふうに運用していた conoHaのVPS CentOS7.3 Dockerで運用している ちなみにDockerは今回が初めて本格的に触った。 マストドンは裏側では3000ポートと4000ポートで待ち受けている。 3000の方は普通のWEB 4000の方はAPIを担当している。 HTTPサーバーであるnginxが、httpの80とhttpsの443で受け取ったら、 それぞれ3000と4000に送りつけている リバースプロキシという技だ。 通常、公開用のhttpとhttpsのポートだけ開けておく。 もちろん僕もそのようにしていた。 CentOS7以降はiptablesではなくfirewalldというファイアウォールのソフトウェアでポートの開け閉めを管理している。 firewalldで、許可するポート
Googleは巨大なインフラをどうやってセキュアに保っているか。独自のセキュリティチップ利用やDoS対策、安全なソフトウェア開発など、全体像を解説したホワイトペーパーを公開
Googleのクラウドは間違いなく世界最大規模のコンピュータシステムです。膨大なハードウェアとソフトウェアから構成されるこの巨大なシステムを、同社はどうやってセキュアに保っているのか。そのことを解説したホワイトペーパー「Google Infrastructure Security Design Overview」が公開されました。 ホワイトペーパーには、Googleのデータセンターを構成するデバイスの1つ1つにまで独自のセキュリティチップを組み込んで正規のデバイスかどうかを相互に認証するという物理レベルのセキュリティから、何層のものロードバランサーからの情報を集約してDos攻撃を検知すると、その通信を破棄するといったDoS対策。 そしてマシンも従業員もサービスも包括するグローバルな名前空間など、きわめて広範かつ綿密なセキュリティ施策が説明されています。 クラウドがいかに高度なセキュリティで
そろそろLDAPにしてみないか？：第7回 ApacheのBasic認証をLDAPで｜gihyo.jp … 技術評論社
Basic認証の危険性とLDAP化の概要 多くの読者の皆さんがご存じのように、パスワード認証を要求するWebページをApache上で作成するためには、通常は.htaccessと.htpasswdなどを用いたBasic認証を使用します。 たとえば、http://www.example.com/secret/以下にてパスワード認証を実現するには次のような設定を行うのが一般的でしょう。 リスト1 .htaccessやhttpd.confの設定（部分） AuthUserFile /home/passwd/.htpasswd AuthGroupFile /dev/null AuthName "Secret Area" AuthType Basic require valid-user リスト2 /home/passwd/.htpasswdの例 tanaka:vDVcobip.AMqE suzuki:
TLS暗号設定ガイドライン 安全なウェブサイトのために（暗号設定対策編） | 情報セキュリティ | IPA 独立行政法人 情報処理推進機構
「TLS暗号設定ガイドライン」は、TLSサーバの構築者や運営者が適切なセキュリティを考慮した暗号設定ができるようにするためのガイドラインです。「様々な利用上の判断材料も加味した合理的な根拠」を重視して、TLS通信での実現すべき安全性と必要となる相互接続性とのトレードオフを考慮した3つの設定基準（「高セキュリティ型」「推奨セキュリティ型」「セキュリティ例外型」）を設けており、各々の設定基準に対応して、TLSサーバで設定すべき具体的な要求設定（「遵守項目」と「推奨項目」）を決めております。 本ガイドラインは安全なウェブサイトの作り方とともに適切な暗号設定をする資料の一つとしてお使いいただけます。 なお、本ガイドラインは、暗号技術評価プロジェクトCRYPTRECで作成されました。 「TLS暗号設定ガイドライン」の内容 1章と2章は、本ガイドラインの目的やSSL/TLSについての技術的な基礎知識を
1
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く
祝RFC！Transport Layer Security (TLS) 1.3 発行の軌跡 ～熟成された4年間の安全性解析～｜株式会社レピダム
TLS徹底演習