AWS×コンテナで基本的なDevSecOpsアーキテクチャをデザインしたお話 - How elegant the tech world is...!
はじめに 先日、僕が担当する業務でECS/Fargate利用を前提にDevSecOpsアーキテクチャをデザインし、社内のAWS勉強会にて登壇する機会をいただきました。 本ブログでも内容をかいつまんでご紹介できればと思います。 AWSによらず、コンテナを利用されている方にとって、一つのプラクティス例としてご参考になれば幸いです。 ※コンテナ自体の説明や必要性に関する内容は省略していますm(_ _)m そもそもDevOpsとは？ DevSecOpsの導入意義をお伝えするた前に、まず軽くDevOpsの意義をお伝えします。 ※とは言え、この記事をご訪問されている方にとっては「何をいまさら...」な内容かもしれませんし、ググればDevOps自体の情報はたくさん見つかりますので、重要なポイントのみ述べることにします。 DevOpsとは、一言で述べれば、開発チームと運用チームが協力してビジネス価値を高め
今なぜHTTPS化なのか？インターネットの信頼性のために、技術者が知っておきたいTLSの歴史と技術背景
【変更履歴 2018年2月15日】当初の記事タイトルは「いまなぜHTTPS化なのか？ 技術者が知っておきたいSEOよりずっと大切なこと ― TLSの歴史と技術背景」でしたが、現行のものに変更しました。現在GoogleではWebサイトのHTTPS対応と検索結果の関係を強調しておらず、本記事の趣旨の一つにも本来は独立した問題であるSEOとHTTPS化を関連付けるという根強い誤解を解くことがありますが、当初のタイトルではかえってSEOとHTTPSを関連付けて読まれるおそれがあり、また同様の指摘もいただいたことから変更いたしました。 HTTPとHTTPSは、共にTCP通信上で動作します。したがって、いずれもTCPハンドシェイクで通信を開始します。 HTTP通信の場合には、このTCPハンドシェイク直後に、HTTPリクエストとレスポンスのやり取りが始まります。このHTTPのやり取りは平文通信であり、途
Linux security tools (top 100)
Hunting the best security toolsThere is a wide range of security tools available for Linux and other platforms. To make them easier to find, we started an extensive review process to gather and document them. The goal of this top 100 is to showcase the best Linux security tools. By best there is an implied level of quality, healthy community and good governance of the project. Requirements for lis
bash 0dayマルウェア感染の「real time」リバースエンジニアリング
ゼロデイが出るといつも大忙し。 特にリバースエンジニアリングの僕らの手が回らない状態です。 《一日目》 CVE-2014-6271（bash 0day）の発表後24時間以内にMalwareMustDieのチームメートから連絡があり、私が調査してマルウェア感染攻撃を発見しました。 https://t.co/CO9AOtHglO Shit is real now. First in-wild attack to hit my sensors CVE-2014-6271 #shellshock #bash ping @MalwareMustDie — Yinette (@yinettesys) September 25, 2014↑調査してくれっていう事で、当時自分は外出中でしたが危なそうだったので急いでPCを開いてバイナリーの分析調査を始めました。 「早く！早く！」とあちこちから催促するメッセ
Basic認証とOAuth - Qiita
Basic認証とOAuthとその辺の情報について整理しておく。OAuthや認証・認可について説明しようとすると、1文字記述するたびに誤りが含まれてしまう可能性があるので、本当に緊張感を持って記述しなければならない。それでもなお、この文章にはたくさんの誤りが含まれている。 UsernameとPasswordを受け取って認証する形式の認証方法。UsernameにはEmailを使うこともある (要は全ユーザの中で一意なことが保証されていてかつ他の人がその値を知っていても特に問題がないという情報であればOK)。Passwordは本人しか知り得ない情報。 OAuthという仕様に則って提供される認可方法。古いOAuth 1.0と、OAuth 1.0の複雑なところなどを改善したOAuth 2.0がある。一般的にはOAuth 2.0を使うことが多いが、例えば幾つかのサービスの提供している認可方法はOAut
無料のSSL証明書StartSSLを活用する - Qiita
背景 自前のサービスでhttps通信をサポートするには、SSL証明書が必要になります。 自分で使用するだけなら、SSL証明書も自前で作成するいわゆるオレオレ証明書を用いても良いのですが、外部に公開するサービスの場合そうとも行きません。 SSL証明書というと値段が高い印象がありましたが、StartSSLというサービスで無料でSSL証明書の発行を受けられると言うことで試してみました。 StartSSLにユーザー登録する 証明書の発行を行う前に、StartSSLにユーザー登録する必要があります。 StartSSLから、"StartSSL Free (Class1)"を選択します。 Certificate Control Panelを選択。 Sign-upに進みます。 名前、住所、メールアドレスなど 個人情報の登録を行います。 登録したメールアドレスに本人確認のメールが届くので、受信したメールのa
GoogleによるOpenSSLのfork、BoringSSLを試す。 - ぼちぼち日記
1. はじめに、 先日、Chrome で 「Issue 401153002: Switch to BoringSSL. (Closed)」 という変更が行われました。これは、従来の Android向け Chrome では OpenSSL を利用していたのですが、今回これをGoogleがOpenSSLをforkしたBoringSSLに切り替えたことになります。 BoringSSLの発表からわずか1か月ぐらいですが、何回か Revert された末ようやく切り替えが成功したようです。 今回 BoringSSL を試しに少し使ってみましたので、そのレポートしてみたいと思います。 2. BoringSSLとは何か BoreingSSLがどういうもので、なぜOpenSSLをforkしたかは、GoogleのセキュリティExpert agl さんのブログ「ImperialViolet - BoringSS
CTF for Beginners のバイナリ問題を見てみた - security etc...
SECCON2014 オンライン予選もひと段落した。 前回のエントリ書いたときにreversing力が欲しいとか思ったので、手始めにCTF for Beginnersのバイナリを見てみた。 といってもそこまでちゃんと見たわけではないけど…。 問題名とかは忘れてしまったので、バイナリファイル5つをファイル名順に見ていく。 第1回に参加したため、第2回とは問題ファイルが違っているかもしれない。 なお、IDAはデモ版でなくてFree版を使っている。 なぜデモ版を使わないの？ と言われると特に理由はないです。しいて言えばデモ版のメリット/デメリットを評価できてないからかな。 今度調べてみよう。てか有償版ほしい。 ctf_bin1 ctf_bin1 ファイルが与えられるため、fileコマンドで確認する。 [root@kali] # file ctf_bin1 ctf_bin1: Microsoft
はてなグループの終了日を2020年1月31日(金)に決定しました - はてなの告知
はてなグループの終了日を2020年1月31日(金)に決定しました 以下のエントリの通り、今年末を目処にはてなグループを終了予定である旨をお知らせしておりました。 2019年末を目処に、はてなグループの提供を終了する予定です - はてなグループ日記 このたび、正式に終了日を決定いたしましたので、以下の通りご確認ください。 終了日: 2020年1月31日(金) エクスポート希望申請期限:2020年1月31日(金) 終了日以降は、はてなグループの閲覧および投稿は行えません。日記のエクスポートが必要な方は以下の記事にしたがって手続きをしてください。 はてなグループに投稿された日記データのエクスポートについて - はてなグループ日記 ご利用のみなさまにはご迷惑をおかけいたしますが、どうぞよろしくお願いいたします。 2020-06-25 追記 はてなグループ日記のエクスポートデータは2020年2月28
【AWSセキュリティ】簡易侵入検知のススメ | DevelopersIO
よく訓練されたアップル信者、都元です。ブログのエントリみてればわかるとおもいますが、最近AWSのセキュリティに凝ってます。 AWSにおける権限管理について知識を深め、各所に適切な設定を行って行くのは大事なことです。これが基本です。しかし、自分が管理するAWSの各種リソースについて、何らかの意図しない変更があったことにすぐ気付ける体制は整っていますでしょうか？ 仮に、アクセスキーが悪意のある第三者に漏洩し、当人がその事実に気づいていないケースを考えます。悪意の第三者は、きたる攻撃のタイミングに備え、各所にバックドアを仕込もうとするでしょう。 こっそりとIAMユーザを増やしているかもしれません。 アクセスキーが1ユーザにつき2つ作れることをいいことに、自分用のキーを追加で作成しているかもしれません。 IAMロールに対するIAMポリシーを書き換えているかもしれません。 セキュリティグループにおけ
1
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く
Cyber Mastery: Community Inspired. Enterprise Trusted. | Hack The Box
AWS のマネージドサービスを使ったセキュリティ強化のための自動化 / aws-security-automation - Speaker Deck
ネットマネーラボ
他人事ではないWebセキュリティ
オープンリゾルバー～正規キャッシュDNSサーバー経由の2段階DDoS攻撃か？ 警察庁が怪しいパケットの増加を観測
co.jp への TXT 追加の謎