BeyondProd | Documentation | Google Cloud
Send feedback BeyondProd Stay organized with collections Save and categorize content based on your preferences. This content was last updated in May 2024, and represents the status quo as of the time it was written. Google's security policies and systems may change going forward, as we continually improve protection for our customers. This document describes how Google implements security in our i
ポスト量子暗号 TLS が AWS KMS でサポートされました | Amazon Web Services
Amazon Web Services ブログ ポスト量子暗号 TLS が AWS KMS でサポートされました AWS Key Management Service (AWS KMS) が KMS API エンドポイントに接続する際に使われる Transport Layer Security (TLS) ネットワーク暗号化プロトコルにおけるポスト量子暗号ハイブリッド鍵交換をサポートしました。この投稿では、ポスト量子暗号 TLS とは何か、 ハイブリッド鍵交換とは何か、 なぜこれらの技術が重要か 、この機能でどのようなメリットを得られるのか、そしてフィードバックの方法について説明します。 ポスト量子暗号 TLS とは? ポスト量子暗号 TLS は、ポスト量子暗号の暗号プロトコルを追加する機能です。 AWS はオープンソースの TLS 実装である s2n を使用しています。2019年6月に
SPAでのセッション管理とセキュリティ - Qiita
基本 普通にcookie使えばいいと思います。 loginリクエストもajaxで投げればcookie返ってくるので、何も考えることないかなと。 Cookie 動作イメージは以下の形です。 == サーバ → UA == Set-Cookie: SID=31d4d96e407aad42; Path=/; Domain=example.com == UA → サーバ == Cookie: SID=31d4d96e407aad42 (from https://triple-underscore.github.io/RFC6265-ja.html) ブラウザの状態管理のためのもの。 もちろん主要ブラウザはどこも付いてます。 railsでもplayでもとりあえずこれでセッション管理されています。 secure属性があると、httpsのときだけやりとりされます。 HttpOnly属性があると、jsから読
日本年金機構の情報漏えいについてまとめてみた - piyolog
2015年6月1日、職員PCがマルウェアに感染したことにより、情報漏えいが発生したことを日本年金機構が発表しました。ここでは関連情報をまとめます。 公式発表 日本年金機構 2015年6月1日 (PDF) 日本年金機構の個人情報流出について 2015年6月3日 (PDF) 個人情報流出のお詫び - 日本年金機構 理事長 水島藤一郎 (平成２７年６月２日) 2015年6月3日 (PDF) 個人情報流出の報道発表を悪用した不審な電話等にご注意ください！ 2015年6月3日 (PDF) 日本年金機構の個人情報が流出したお客様へのお詫びについて 2015年6月6日 (PDF) 日本年金機構ホームページの一時停止について 2015年6月8日 (PDF) 日本年金機構ホームページの暫定対応について 2015年6月22日 (PDF) 日本年金機構の個人情報が流出したお客様へのお詫びについて 2015年6月
AWS で作るシステムのセキュリティ考 - 水深1024m
AWS アカウントを複数人で使ってシステムを作っていく時に、 セキュリティの面からやるべきことについて。 主に Web アプリケーションを想定した内容ですが、特に書いてあることは特殊ではないと思います。 各所の Blog にも記事書かれてますが思っていることをつらつらと書いてみます。 なんか変なこと言ってたらご指摘ください。 参考: AWSのセキュリティが気になるなら読んでおくべきAWSセキュリティのベストプラクティス - yoshidashingo はじめに (AWS アカウントと IAM ユーザ) 前提というか用語の話。 AWS アカウント アカウント作成時のメールアドレス、パスワードでログインして使うユーザ IAM ユーザ AWS アカウントから発行できる、ユーザ名とパスワードでログインして使うユーザ AWS アカウント周り AWS アカウント (ルートユーザ) で作業できないように
自堕落な技術者の日記 : ChromeのSHA1証明書のアラート表示ポリシの問題点 - livedoor Blog（ブログ）
表を見ていただければわかる通り、Microsoft WindowsのSHA1移行ポリシに比べて、Chromeはかなりアグレッシブな設定になっており、開発版は2014年9月26日のアップデートから、安定版は2014年11月頃リリースの39から正常なHTTPS接続でないかのようなステータス表示となってしまいます。 今回のChromeのSHA1対応ポリシの問題点 今回のGoogle ChromeのSHA1証明書に対する対応計画は様々な問題があると考えていて、論点を整理したいと思います。 最も重要だと思うのが、ブラウザ毎にHTTPSのエラーや問題に対する表示の意味が異なってしまうという点です。今回のSHA1証明書の表示の計画がブラウザベンダー毎に異なるのはユーザが混乱することになり、良くなかったと思います。本来ならCA Browser ForumのBaseline Profileなどで、業界で意思
Why Google is Hurrying the Web to Kill SHA-1
Hilbert map of hashing algorithms, by Ian Boyd Most of the secure web is using an insecure algorithm, and Google's just declared it to be a slow-motion emergency. Something like 90% of websites that use SSL encryption — — use an algorithm called SHA-1 to protect themselves from being impersonated. This guarantees that when you go to , you're visiting the real Facebook and not giving your password
Nessus on EC2でシステムの脆弱性を検査する | DevelopersIO
はじめに セキュリティはクラウドでもオンプレミスと変わらず重要です。AWSの共有責任モデルにおいて、物理的なファシリティやインフラ部分のセキュリティはAWSにて担保されますが、OSやミドルウェア、アプリケーションについては利用者自らセキュリティレベルを高める必要があります。 そこで今回はAmazon EC2で、脆弱性スキャナであるNessusを使ってみました。 脆弱性スキャナとは 自身が管理しているサーバに対し、侵入やサービス妨害などに用いられる攻撃手段を試行して、脆弱性の有無を確認するツールです。広義で言えば、開放されている通信ポートを調べるポートスキャナも脆弱性スキャナの一種と言えるでしょう。脆弱性スキャナは攻撃手段をパターンとして持ち、ポートスキャンで発見された開放ポートに対して攻撃手段を試行することで、攻撃を受けるリスクの高い脆弱性を発見することが出来ます。 有名なものではReti
エフセキュアブログ : 再録：パスワードは本当にSHA-1+saltで十分だと思いますか？
再録：パスワードは本当にSHA-1+saltで十分だと思いますか？ 2012年06月07日19:05 ツイート sean_sullivan ヘルシンキ発 by：ショーン・サリバン 昨日、一部メンバーのパスワードに障害が起きたという報道を、LinkedInが認めた。 以下は彼らのブログからの情報だ： 「我々が先頃導入した強化版のセキュリティには、現行のパスワードデータベースのハッシュとsaltが含まれており、今回の影響でパスワードを変更するユーザーにも、パスワードに障害が起きていないメンバーにも利益を与えるだろう。」 ハッシュとsalt？ それで十分なのか？ それは以下の再録記事（アップデートを含む）で、昨年、エフセキュアのジャルノ・ネメラが呈した疑問だ。 ————— アナーキーなインターネットグループ「Anonymous」が先頃、HBGary Federalとルートキットテクノロジの分析
連載: IBM Watson Workspace #鬼わか アプリケーション開発: 第 7 回: IBM Watson Workspace で AI を利用したアプリ連携の実現 #鬼わか 解説（前編）
単なる OAuth 2.0 を認証に使うと、車が通れるほどのどでかいセキュリティー・ホールができる
In some of the feedback I have gotten on the openID Connect spec, the statement is made that Connect is too complicated. That OAuth 2.0 is all you need to do authentication. Many point to Identity Pro… 英語読みたくないという人のために簡単に解説すると… OAuth 2.0 の implicit flow を使って「認証」をしようとすると、とっても大きな穴が開きます。 カット＆ペーストアタックが可能だからです。 OAuth 認証？は、図１のような流れになります。 図１ OAuth 認証？の流れ 一見、問題なさそうに見えます。しかし、それはすべてのサイトが「良いサイト」ならばです。 Site_A
1
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く
ビズリーチ、脆弱性と対応優先度を自動で可視化するオープンソース脆弱性管理ツール「yamory」をリリース
http://blog.monoweb.info/article/2012031523.html