並び順

ブックマーク数

期間指定

  • から
  • まで

1 - 40 件 / 81件

新着順 人気順

インシデントとはの検索結果1 - 40 件 / 81件

  • 小悪魔女子大生のサーバエンジニア日記

    ECC版SSL証明書インストール体験記その4 02.08.13 / 未分類 / Author: aico / Comments: (0) では、いよいよ発行されたECC証明書をインストールしましょう! 実はECC版SSL証明書は現在、ブラウザ・OSによっては対応していないものも多いので、 対応していないものはRSAの証明書を読むように、ECCとRSAのハイブリッド構成をすることが出来ます。 そしてなんと、ECCの証明書を申請するとRSAの証明書も一緒にもらうことが出来ます(ベリサインさん太っ腹!) なので今回はECCとRSAのハイブリッド構成を組みつつ証明書のインストールを行います! まずはベリサインのサイトで中間証明書を確認しましょう。 発行されたCRT、中間証明書、秘密鍵は必ず対になっている必要があります。 対になっていないとエラーになってしまいます。。 小悪魔ブログは最初、中間証明書

    • 6年勤めたNTTを退職しました - Software Transactional Memo

      最終退社時の自分の机 2012年に修士卒からの新卒でNTT研究所に入り、6年間お世話になりました。 研究所では同期や先輩や後輩や上司に恵まれ、存分に書籍や論文を読んで勉強して力を蓄えたり、対外的な発表の場にも恵まれ外ではできないような体験をすることができました。 ありがとうございました。 入社当時に作られたtogetterを見返すと togetter.com togetter.com まるで昨日のように感じられる。 NTT社内で僕が何をやっていたかについては言える物は軒並みアウトプットされているのでわざわざここでは触れない。 NTT研究所について NTT研究所を客観的に見た時にどうかを書いていく とにかく人に恵まれている。採用の倍率が高いのもあって潤沢な学生エントリーからよりすぐりのエリートが謎の力でポテンシャルを見極められて採用されている。同期を見てひと目ですごい奴も居れば、一見してわか

        6年勤めたNTTを退職しました - Software Transactional Memo
      • GitLab.comが操作ミスで本番データベース喪失。5つあったはずのバックアップ手段は役立たず、頼みの綱は6時間前に偶然取ったスナップショット - Publickey

        果たしてGitLab.comで何が起きたのでしょうか? これまでの経緯をまとめました。 スパムによるトラフィックのスパイクからレプリケーションの不調へ GitLab.comは今回のインシデントについての詳細な経過を「GitLab.com Database Incident - 2017/01/31」で公開しています。また、もう少し整理された情報がブログ「GitLab.com Database Incident | GitLab」にも掲載されています。 これらのドキュメントを軸に、主なできごとを時系列に見ていきましょう。 1月31日16時(世界協定時。日本時間2月1日午前8時)、YP氏(Yorick Peterse氏と思われる)はPostgreSQLのレプリケーションを設定するためにストレージの論理スナップショットを作成。これがあとで失われたデータを救う幸運につながります。 1月31日21時

          GitLab.comが操作ミスで本番データベース喪失。5つあったはずのバックアップ手段は役立たず、頼みの綱は6時間前に偶然取ったスナップショット - Publickey
        • 牧歌的 Cookie の終焉 | blog.jxck.io

          Intro Cookie は、ブラウザに一度保存すれば、次からその値を自動的に送ってくるという、非常に都合の良い仕様から始まった。 State Less が基本だった Web にセッションの概念をもたらし、今ではこれが無ければ実現できないユースケースの方が多い。 冷静に考えればふざけてるとして思えないヘッダ名からもわかるように、当初はこのヘッダがこんなに重宝され、 Web のあり方を変えるかもしれないくらい重要な議論を巻き起こすことになるとは、最初の実装者も思ってなかっただろう。 そんな Cookie が今どう使われ、 3rd Party Cookie (3rdPC) の何が問題になっているのかを踏まえ、これからどうなっていくのかについて考える。 Cookie のユースケース Web にある API の中でも Cookie はいくつかの点で特異な挙動をする 一度保存すれば、次から自動で送る

            牧歌的 Cookie の終焉 | blog.jxck.io
          • ミスが全くない仕事を目標にすると、ミスが報告されなくなる『測りすぎ』

            たとえば天下りマネージャーがやってきて、今度のプロジェクトでバグを撲滅すると言い出す。 そのため、バグを出したプログラマやベンダーはペナルティを課すと宣言する。そして、バグ管理簿を毎週チェックし始める。 すると、期待通りバグは出てこなくなる。代わりに「インシデント管理簿」が作成され、そこで不具合の解析や改修調整をするようになる。「バグ管理簿」に記載されるのは、ドキュメントの誤字脱字など無害なものになる。天下りの馬鹿マネージャーに出て行ってもらうまで。 天下りマネージャーが馬鹿なのは、なぜバグを管理するかを理解していないからだ。 なぜバグを管理するかというと、テストが想定通り進んでいて、品質を担保されているか測るためだ。沢山テストされてるならバグは出やすいし、熟知しているプログラマならバグは出にくい(反対に、テスト項目は消化しているのに、バグが出ないと、テストの品質を疑ってみる)。バグの出具

              ミスが全くない仕事を目標にすると、ミスが報告されなくなる『測りすぎ』
            • ソフトウェアエンジニアなら3秒で理解できる NFT 入門 - Okapies' Archive

              はじめに NFT って何ですか? ブロックチェーン上に記録された一意なトークン識別子をその保有者のアドレスと紐付ける情報、およびそれを状態変数として保持するスマートコントラクトのこと。 以上。 え、それだけ? はい。 「デジタル資産に唯一無二性を付与するインターネット以来の革命」なんじゃないの? これを読んでください: speakerdeck.com なるほど。ところで、この記事は何? いま話題の NFT について、NFT の標準仕様である EIP-721 の仕様書と、それを実装しているスマートコントラクトのソースコードから読み解けることを解説する。一般向けの解説とは異なる視点から光を当てることで、ソフトウェアエンジニアに「あ、NFT って単にそういうことだったのか」と理解してもらえるようにすることを狙っている。 また、NFT がソフトウェアとして具体的にどう実装されているかを知ることは、

                ソフトウェアエンジニアなら3秒で理解できる NFT 入門 - Okapies' Archive
              • 「男性はぶつかってくる」は本当か

                当方、20代女性である。 先日ついうっかり足を捻挫してしまい、しばらく松葉杖生活となった。 その際に気付いたことがあるので書き留めておこうと思う。 「男性はぶつかってくる」 男性は駅や街の雑踏でぶつかってくる。それは女性を無意識に見下していて、避けないからだ。 これは女性なら多かれ少なかれ心のなかに共有された理解であると思う。私もそう思っていた。 もちろんわざわざぶつかってくる一種の変態もいる。彼らを置いておいて、男性一般に関しての話だ。 あくまでも個人ではなく集団としてである。 「日本人は酒が弱い」「日本人は清潔を好む」 これらは集団としては成立するが、これを個人個人に還元しようとするのはナンセンスだろう。あくまでもマクロな話であると念を押しておく。 私が気付いたのは、「女性はぶつかってくる」ということである。 私は定期の関係で新宿や秋葉原でよく下車するため、コロナ禍の中でも雑踏を通る機

                  「男性はぶつかってくる」は本当か
                • セキュリティエンジニアになり、そこから2年間分の勉強内容と参考になった資料とか - ぶるーたるごぶりん

                  セキュリティエンジニアになり、そこから2年間分の勉強内容と参考になった資料とか 自分の振り返りも兼ねて2年分の勉強内容とかをざっくりまとめようと思います。 新卒からバックエンド開発を2年程行い、その後セキュリティエンジニアとして横断セキュリティ部門に異動しました。 そこから更に2年が経ち、来月からセキュリティサービスの開発とかをすることになったので、 もし同じような人が居た際になんとなし参考になればいいかなという意図で書いてます。 ちなみにセキュリティ部門に異動するまでのセキュリティの知識レベルは「徳丸本を2回通しで読んでる」程度です。 セキュリティ部門に移ってからは脆弱性診断・ログ監視・開発ガイドライン周り・脆弱性管理とかをやってました。 本記事では自分自身がユーザ系の企業に属しているので、ベンダーとかそちら寄りの内容ではないです。 あとできる限り社内の事情を記載しません。何が問題になる

                    セキュリティエンジニアになり、そこから2年間分の勉強内容と参考になった資料とか - ぶるーたるごぶりん
                  • プロダクトマネジメントと事業開発に関する私的な振り返り - 下町柚子黄昏記 by @yuzutas0

                    TL;DR 企画力が…欲しい… pic.twitter.com/hJfr0qNv7T— ゆずたそ (@yuzutas0) 2020年11月19日 試行錯誤の瓦礫の記録です。 はじめに もくじ TL;DR はじめに もくじ 以前書いた記事 前提・免責 アイデア 1日1案(やってよかったこと) 1stスクリーニング(やってよかったこと) コミュニケーション チームへのリスペクト(やってよかったこと) 話す <<< 聞く(改善余地あり) 即決する(やってよかったこと) 自分で各論まで見る(やってよかったこと) 発散→収束でディスカッション(改善余地あり) イラストで話す(改善余地あり) 日次ミーティング(やってよかったこと) 議事録を書く(改善余地あり) 得た情報を共有する(改善余地あり) 想定納期を示す(改善余地あり) カレンダー招待&日程確約コメントを転記(改善余地あり) プロセス管理 仮説

                      プロダクトマネジメントと事業開発に関する私的な振り返り - 下町柚子黄昏記 by @yuzutas0
                    • ミスを責めるとミスが増え、自己正当化がミスを再発する『失敗の科学』

                      人はミスをする。これは当たり前のことだ。 だからミスしないように準備をするし、仮にミスしたとしても、トラブルにならないように防護策を立てておく。人命に関わるような重大なトラブルになるのであれば、対策は何重にもなるだろう。 個人的なミスが、ただ一つの「原因→結果」として重大な事故に直結したなら分かりやすいが、現実としてありえない。ミスを事故に至らしめた連鎖や、それを生み出した背景を無視して、「個人」を糾弾することは公正なのか? 例えば、米国における医療ミスによる死亡者数は、年間40万人以上と推計されている(※1)。イギリスでは年間3万4千人もの患者がヒューマンエラーによって死亡している(※2)。 回避できたにもかかわらず死亡させた原因として、誤診や投薬ミス、手術中の外傷、手術部位の取り違え、輸血ミス、術後合併症など多岐にわたる。数字だけで見るならば、米国の三大死因は、「心疾患」「がん」そして

                        ミスを責めるとミスが増え、自己正当化がミスを再発する『失敗の科学』
                      • アメリカの職場ではなぜドキュメントも無いのに人が去っても問題ないのだろう?|牛尾 剛

                        アメリカの職場にいると、日本にいるときよりも身近でレイオフだとか、職を変えるというのを頻繁に見かける。先日もそういう場面があったのだが昔日本で働いていた時のことを思い出した。 ドキュメントを書く理由 日本のソフトウェア企業にいたときは、「納品物であるから」という理由以外にも、「人がいなくなったときに会社が困るから」という理由でもドキュメントを書くことが推奨されていた。しかし、少なくとも今の職場ではそんな理由でドキュメントを書くのは推奨されていないのに、なぜ問題にならないのだろうとふと思った。 うちのマネージャは、バディ制ににして、みんな休暇できるようにしようとは言っているが、多分本当に退職対策ではないと思う。 チームのメンバーが抜けたときも、「とても残念で、ワークロードをどうしようという問題はあるけど、彼女の門出を祝福しよう」言っていた。つまり、こちらでも「工数」は問題になるけど、「引継ぎ

                          アメリカの職場ではなぜドキュメントも無いのに人が去っても問題ないのだろう?|牛尾 剛
                        • 「生成AIを仕事で使い倒す人たち」に取材して回ったら「自分の10年後の失業」が見えてしまった

                          ChatGPTの発表から、1年が経過しようとしています。 熱狂は徐々に醒め、現在の利用状況はLINEの調査によると、全体の5%程度。*1 その中でも、仕事で積極的に利用している人は、1%程度ではないかと推測します。 では、この1%の人たちはどのような方々で、どのように生成AIを仕事で使っているのか? 9月の中旬から、10月の末にかけて、私は約40名の方に取材を行いました。 そして、私は一つの確信を得ました。 それは、「私は間違いなく10年後、失業する」です。 私は間違いなく10年後、失業する なぜなら、現場での生成AI利用は、仕事によっては 「ホワイトカラーの代替」 をかなり高いレベルでできることがわかったからです。 例えば、コンサルティング。 コンサルティングには、初期の段階で、仮説構築という仕事があります。 平たく言うと、調査・提案にあたって「課題はここにあるのではないか?」というアタ

                            「生成AIを仕事で使い倒す人たち」に取材して回ったら「自分の10年後の失業」が見えてしまった
                          • ソースコードブランチ管理のパターン - Martin Fowler's Bliki (ja)

                            https://martinfowler.com/articles/branching-patterns.html 最新のソース管理システムには、ソースコードのブランチを簡単に作成できる強力なツールが用意されています。しかし、最終的にはこれらのブランチをマージしなければならず、多くのチームは混み合ったブランチに対処するのに膨大な時間を費やしています。複数の開発者の作業をインテグレーションし、本番リリースまでの道筋を整理することに集中して、チームが効果的にブランチを利用できるようにするためのパターンがいくつかあります。全体的なテーマとしては、ブランチを頻繁にインテグレーションし、最小限の労力で本番環境に展開できる健全なメインラインを作ることに注力すべきだということです。 ベースパターン ソースブランチング ✣ メインライン ✣ 健全なブランチ ✣ インテグレーションパターン メインラインイン

                            • 日本年金機構の情報漏えいについてまとめてみた - piyolog

                              2015年6月1日、職員PCがマルウェアに感染したことにより、情報漏えいが発生したことを日本年金機構が発表しました。ここでは関連情報をまとめます。 公式発表 日本年金機構 2015年6月1日 (PDF) 日本年金機構の個人情報流出について 2015年6月3日 (PDF) 個人情報流出のお詫び - 日本年金機構 理事長 水島藤一郎 (平成27年6月2日) 2015年6月3日 (PDF) 個人情報流出の報道発表を悪用した不審な電話等にご注意ください! 2015年6月3日 (PDF) 日本年金機構の個人情報が流出したお客様へのお詫びについて 2015年6月6日 (PDF) 日本年金機構ホームページの一時停止について 2015年6月8日 (PDF) 日本年金機構ホームページの暫定対応について 2015年6月22日 (PDF) 日本年金機構の個人情報が流出したお客様へのお詫びについて 2015年6月

                                日本年金機構の情報漏えいについてまとめてみた - piyolog
                              • みずほ銀行システム障害に学ぶ

                                みずほ銀行システム障害の調査報告書が公開されたのがニュースになって、Twitterなどで色々な人がコメントをしているのを見た。140文字しか書けない空間で他人の失敗談の揚げ足取りをするのは簡単だが、そこからは一時の爽快感以外に何も得るものがないので、僕はそういうのはカッコ悪いと思っている。 そこで、ちゃんと読んでみたら全く他人事でない部分も沢山あるし、非常に面白く勉強になったので、ブログにまとめてみる。 技術的な話 銀行のシステムがどのようになっているのか、全然イメージが湧いていなかったので、それがまず勉強になった(p.29)。 トラフィックのソースに応じて用意された色々なシステムから基幹システム「MINORI」の取引メインバスにトラフィックが流れ、そこから各種システムへとリクエストが送られていく。この辺はService Oriented Architectureらしい。開発当時としては(

                                  みずほ銀行システム障害に学ぶ
                                • 「次から気をつけます」に対抗する、反省文よりは効果が上がる再発防止、学びの機会 - Qiita

                                  再発防止策を書くのは難しい。 良い再発防止策 良い再発防止策について、順位付けするとしたら、 その種類の問題について二度と意識することがなくなる解決策 その種類の問題を開発時に自動的に検知することができる解決策 その種類の問題が発生しても自動的に復旧することができる解決策 その種類の問題が発生しても影響が局所化される、フールプルーフ、フェールセーフになる解決策 と言うのは意識したいと思いつつ、やはり難しい。 再発防止はむずかしい 障害の再発防止策は、 メカニズム ツール ルール チェックリスト の順番に検討せよ。と言われても、急いで書けなんて言われると「次回からは複数人でチェックします。」とか「チェック項目を追加します。」とかいう徹底できなそうな「反省文」になってしまう。 まさにこの有名な猫...。 **「なぜミスを繰り返すのか」「どうすればミスを防げるのか」を真剣に考えていないことがミス

                                    「次から気をつけます」に対抗する、反省文よりは効果が上がる再発防止、学びの機会 - Qiita
                                  • 私のセキュリティ情報収集法を整理してみた(2021年版) - Fox on Security

                                    新年あけましておめでとうございます。毎年年頭に更新している「私の情報収集法」を今年も公開します。何かの参考になれば幸いです。 インプットで参照している情報源(海外) 海外からの攻撃が主流となる中、海外情報をいち早く把握する事の重要性が増している気がしますので、今年は海外情報源から書きたいと思います。 昨年の記事では多くの海外サイトを紹介しましたが、試行錯誤の結果、まとめサイトでもある「morningstar SECURITY」や「DataBreaches.net」を押さえておけば、主要サイトが概ねカバーされると分かったので、今年は数を絞っています。 サイト キタきつね寸評 morningstar SECURITY 去年と変わりませんが、情報の更新頻度、そして関連ソースの網羅性という意味では、英語系のセキュリティニュースとしては最良の情報ソースの1つかと思います。私は「Daily Secur

                                      私のセキュリティ情報収集法を整理してみた(2021年版) - Fox on Security
                                    • 単なる 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 認証?は、図1のような流れになります。 図1 OAuth 認証?の流れ 一見、問題なさそうに見えます。しかし、それはすべてのサイトが「良いサイト」ならばです。 Site_A

                                        単なる OAuth 2.0 を認証に使うと、車が通れるほどのどでかいセキュリティー・ホールができる
                                      • JTBへの不正アクセスについてまとめてみた - piyolog

                                        2016年6月14日、JTBは同社のサーバーが不正アクセスを受け、顧客情報が漏えいした可能性があると発表しました。ここでは関連情報をまとめます。 公式発表 今回の不正アクセスによる影響はJTB他、同社の提携サービスを展開している他社にも波及している。 JTBグループ 2016年6月14日 不正アクセスによる個人情報流出の可能性について 2016年6月14日 Re: Occurrence of Unauthorized Access (魚拓) 2016年6月16日 個人情報流出の可能性があるお客様へのご連絡について 2016年6月17日 「なりすましメール」「フィッシングメール」や「なりすましサイト」にご注意ください JTB提携先 NTTドコモ 2016年6月14日,16日 提携先のJTB社のグループ会社サーバーへの不正アクセスに伴う「dトラベル」の個人情報流出の可能性について (魚拓) (

                                          JTBへの不正アクセスについてまとめてみた - piyolog
                                        • AWSアカウントを作ったら最初にやるべきこと ~令和元年版~ | DevelopersIO

                                          はじめに 中山(順)です 4年ほど前にこの記事のタイトルと同じテーマで資料を作成したことがあるのですが、古い内容があったり新しいサービスのことが含まれていなかったりするので改めてまとめてみました。令和だし! その時の資料はこちらです(クラスメソッドにジョインするくらい2年前です)。 AWSアカウントを作ったら最初にやるべきこと サインアップ (業務利用の場合)非個人メールアドレスでサインアップ サポートプランの確認 ID管理 / 権限管理 CloudTrailの有効化 ルートアカウントのMFA設定 IAM User / IAM Groupの作成 パスワードポリシーの設定 GuardDutyの有効化 Security Hubの有効化 請求 IAM Userによる請求情報へのアクセス許可 支払通貨の変更 Budgetの設定 Cost Explorerの有効化 Cost Usage Report

                                            AWSアカウントを作ったら最初にやるべきこと ~令和元年版~ | DevelopersIO
                                          • 私たちはいかにして環状線で”悪さをする列車”を捕まえたか | プログラミング | POSTD

                                            文:Daniel Sim 分析:Lee Shangqian、Daniel Sim、Clarence Ng ここ数ヶ月、シンガポールのMRT環状線では列車が何度も止まるものの、その原因が分からないため、通勤客の大きな混乱や心配の種となっていました。 私も多くの同僚と同じように環状線を使ってワンノースのオフィスに通っています。そのため、11月5日に列車が止まる原因を調査する依頼がチームに来た時は、ためらうことなく業務に携わることを志願しました。 鉄道運営会社SMRTと陸上交通庁(LTA)による事前調査から、いくつかの電車の信号を消失させる信号の干渉があり、それがインシデントを引き起こすことが既に分かっていました。信号が消失すると列車の安全機能である緊急ブレーキが作動するため、不規則に電車が止まる原因となります。 しかし8月に初めて発生した今回のインシデントは、不規則に起こっているように見えるた

                                              私たちはいかにして環状線で”悪さをする列車”を捕まえたか | プログラミング | POSTD
                                            • 私たちは心理的安全性を誤解していたかもしれない。 - Qiita

                                              はじめに 最近、新入社員の方が毎月のように入社されていて、うちの部署もにぎわってきたなーと感じています。 やっぱり、人が増えてくるといろんな方がいてコミュニケーションの大切さを実感しています。 うちの部署では、事業部で大切にしていることの一つに心理的安全性があるので、それについて考えてみたいと思います。 心理的安全性とは? 心理的安全性とは何でしょうか?ググってみると 「心理的安全性とは、職場で誰に何を言っても、人間関係が壊れることなく、罰を受ける心配もない状態のこと。」と出てきます。 これだけだと抽象的で、よくわかりませんね そこで心理的安全性を提唱したエイミー・C・エドモンドソン先生の「恐れのない組織」を読んでみました。 本書では様々なケーススタディから組織での心理的安全性について書かれています。 心理的安全性の高い組織はどういうものかざっくり要約すると 「このままではまずいのでは?」

                                                私たちは心理的安全性を誤解していたかもしれない。 - Qiita
                                              • IPA のけしからん技術が再び壁を乗り越え、セキュアな LGWAN 地方自治体テレワークを迅速に実現

                                                IPA のけしからん技術が再び壁を乗り越え、セキュアな LGWAN 地方自治体テレワークを迅速に実現 2020 年 11 月 3 日 (火) 独立行政法人情報処理推進機構 (IPA) 産業サイバーセキュリティセンター サイバー技術研究室 登 大遊 独立行政法人 情報処理推進機構 (IPA) 産業サイバーセキュリティセンター サイバー技術研究室は、このたび、できるだけ多くの日本全国の地方自治体 (市町村・県等) の方々が、LGWAN を通じて、迅速に画面転送型テレワークを利用できるようにすることを目的に、J-LIS (地方公共団体情報システム機構) と共同で、新たに「自治体テレワークシステム for LGWAN」を開発・構築いたしました。 本システムは、すでに 8 万ユーザー以上の実績と極めて高い安定性 を有する NTT 東日本 - IPA 「シン・テレワークシステム」をもとに、LGWAN

                                                  IPA のけしからん技術が再び壁を乗り越え、セキュアな LGWAN 地方自治体テレワークを迅速に実現
                                                • 私のセキュリティ情報収集法を整理してみた(2024年版) - Fox on Security

                                                  新年あけましておめでとうございます。毎年この時期に更新している「私の情報収集法(2024年版)」を今年も公開します。 ■はじめに サイバー攻撃は国境を越えて発生するため、ランサムウェア、フィッシング、DDoS攻撃など、近年のサイバー脅威の常連となっている攻撃者(脅威アクター)が主に海外にいることを考えると、世界の脅威動向を理解することが年々重要になっています。 海外から日本の組織が受けるサイバー攻撃の多くでは、国際共同オペレーション等の一部のケースを除き、日本の警察が犯罪活動の協力者(出し子、買い子、送り子)を摘発することはあっても、サイバー攻撃の首謀者(コアメンバー)を逮捕するまで至るケースはほとんどありません。 誤解を恐れずに言えば、日本の組織は海外からの攻撃を受け続けているのに、海外で発生したインシデントや攻撃トレンドの把握が遅れ、対策が後手に回っているケースも多いように感じます。最

                                                    私のセキュリティ情報収集法を整理してみた(2024年版) - Fox on Security
                                                  • 書評「入門 監視」雰囲気で監視をやっているすべての人にオススメ | DevelopersIO

                                                    監視という一種マニアックな領域を真正面から解説した貴重な本です。監視で悩む人のみならずシステム開発に携わるすべての人にオススメ。 「全然わからない。俺たちは雰囲気で監視をやっている」 自分はAWS事業本部コンサルティング部所属ということもあって、いろんなお客様にAWSインフラのコンサルティングしてます。最初のインフラ構成設計時に監視の話をすることも非常に多いんですが、 「どうしましょう。CloudWatchでいけますかね?」 「MackerelとかDatadogとかもありますが、どうしましょ。マネージドとの違いは〜」 「とりあえず、ディスク使用率80%でしきい値設定しておきましょうか。みんなそうしてますよ」 とか言っていた昔の自分に見せつけたい本、それが今回紹介する「入門 監視」。 監視設計の原則がよくわかんない メトリクスのしきい値決めるところから監視を考えてしまいがち よく考えずに、い

                                                      書評「入門 監視」雰囲気で監視をやっているすべての人にオススメ | DevelopersIO
                                                    • 架空企業「オニギリペイ」に学ぶ、セキュリティインシデント対策

                                                      架空企業「オニギリペイ」に学ぶ、セキュリティインシデント対策:徳丸浩氏が8つの試練を基に解説(1/3 ページ) ECサイトやWebサービスでセキュリティインシデントを起こさないためには何をすればいいのか。2019年12月に開かれた「PHP Conference Japan 2019」で徳丸浩氏が、架空企業で起きたセキュリティインシデントを例に、その対策方法を紹介した。 ECサイトやWebサービスを提供する会社で発生したセキュリティインシデントに関するさまざまなニュースが後を絶たない。どうすればこうしたインシデントは防げるのだろうか。 『体系的に学ぶ安全なWebアプリケーションの作り方』(通称:徳丸本)の筆者として知られる徳丸浩氏(EGセキュアソリューションズ 代表取締役)は、2019年12月に開かれた「PHP Conference Japan 2019」のセッション「オニギリペイのセキュリ

                                                        架空企業「オニギリペイ」に学ぶ、セキュリティインシデント対策
                                                      • 普段使いはメガバンクや地銀よりもネット銀行のほうがお得。年間数千〜数万円は節約できるぞ

                                                        この記事には広告を含む場合があります。 記事内で紹介する商品を購入することで、当サイトに売り上げの一部が還元されることがあります。 Money – Savings / 401(K) 2013 今これを読んでいる人の中で、「銀行を使っていない」という人はまずいないでしょう。 誰もが給料や仕送りの振込み先として銀行口座を使い、必要なときにお金を引き出しているはずです。 銀行は、本来なら預けることで多少なりともお金が増える仕組みのはず。 ですが実際には、低すぎる金利による利息よりもATM手数料や振込手数料のほうがはるかに大きく、お金が減っている人のほうが多いのではないでしょうか。 利率が極端に低い一方で、夜や休日に引き出しをすると手数料が取られ…大部分の方はお金が減っているはず。 普段使いの普通口座に限定すれば、もうほとんどの人がマイナスに違いない、と言っていいくらい。 お金をできるだけ減らさな

                                                          普段使いはメガバンクや地銀よりもネット銀行のほうがお得。年間数千〜数万円は節約できるぞ
                                                        • SIerとは何か、何であるべきか ― 偉大ならざるリスクテイカー|ミック

                                                          はい、今回はみんな大好き(大嫌い)SIerについての話である。 デジタル庁の動きに駆動されて、日本で何度目かの内製推進が盛り上がろうとしている。 日本のITシステム開発がうまく行かない原因としてしばしば挙げられるのが、ユーザサイド(非IT産業)にエンジニアやプログラマなどのIT人材が不足しているというものだ。確かに、日本が欧米と比較してIT企業にIT人材を集中的に配置しているのは事実である。 こうしたIT人材の偏りによって、アジリティの高い開発ができない、CI/CDやDevOpsが進まない、というのは当たっているし、ユーザ企業も自らIT人材を雇用して内製を進めるべきだ、という議論にはもう十年以上の歴史がある(筆者が追えていないだけでもっと古いかもしれない)。 この時、悪玉として批判にさらされるのが、今回の主役であるSIerという存在である。日本における内製推進は、しばしばSIer批判とセッ

                                                            SIerとは何か、何であるべきか ― 偉大ならざるリスクテイカー|ミック
                                                          • 障害報告書を書こう! - Qiita

                                                            担当しているITサービスなどに何かしらのインシデントや障害が発生した時に、対処後のアクションとして報告書を提出して事象の内容を報告(レポート)する場合がある。 提出先は会社の偉い人だったりクライアントだったり。場合によってはユーザー向けに発表したり。事の顛末を報告して「今後同様のことを起こさないように努力します、ごめんなさい」をするのだ。どのように再発防止の努力するのかを書くものでもある。 主にクライアント向けのビジネス内容ではあるが、自分が使っているテンプレパターンを共有するので参考にしてもらえればと思う。1 全般的なポイント 心得のようなもの。次の点は留意してて欲しい。 淡々と冷静な説明をこころがける 当然のことながら事実は脚色しない。無駄な修飾も要らない。客観的な事実を簡潔に述べる。 例: ❌「一生懸命頑張って対応したが…」 ❌「寝ないで対応したが…」 ❌「本当の原因は…」 できるだ

                                                              障害報告書を書こう! - Qiita
                                                            • JASRAC、音楽教室に「潜入」2年 主婦を名乗り:朝日新聞デジタル

                                                              ","naka5":"<!-- BFF501 PC記事下(中⑤企画)パーツ=1541 -->","naka6":"<!-- BFF486 PC記事下(中⑥デジ編)パーツ=8826 --><!-- /news/esi/ichikiji/c6/default.htm -->","naka6Sp":"<!-- BFF3053 SP記事下(中⑥デジ編)パーツ=8826 -->","adcreative72":"<!-- BFF920 広告枠)ADCREATIVE-72 こんな特集も -->\n<!-- Ad BGN -->\n<!-- dfptag PC誘導枠5行 ★ここから -->\n<div class=\"p_infeed_list_wrapper\" id=\"p_infeed_list1\">\n <div class=\"p_infeed_list\">\n <div class=\"

                                                                JASRAC、音楽教室に「潜入」2年 主婦を名乗り:朝日新聞デジタル
                                                              • ベネッセの情報漏えいをまとめてみた。 - piyolog

                                                                2014年7月9日、ベネッセホールディングス、ベネッセコーポレーションは同社の顧客情報が漏えいしたと発表を行いました。ここではその関連情報をまとめます。 (1) 公式発表と概要 ベネッセは同社の顧客情報が漏えい、さらに漏えいした情報が第三者に用いられた可能性があるとして7月9日に発表をしました。また7月10日にDM送付を行ったとしてジャストシステムが報じられ、それを受けて同社はコメントを出しています。またさらにその後取引先を対象として名簿を販売したと報じられている文献社もコメント及び対応について発表しています。7月17日にECCでも漏えい情報が含まれた名簿を使ってDMの発送が行われたと発表しています。 ベネッセホールディングス(以下ベネッセHDと表記) (PDF) お客様情報の漏えいについてお詫びとご説明 (PDF) 7月11日付株式会社ジャストシステムのリリースについて (PDF) 個人

                                                                  ベネッセの情報漏えいをまとめてみた。 - piyolog
                                                                • AWSアカウントを取得したら速攻でやっておくべき初期設定まとめ - Qiita

                                                                  AWSアカウントを作成したら最初にやっておきたいことをまとめてみた。 あわせて読みたい 本記事の内容を含めた最新の手順は、下記の書籍にまとまっている。 クラウド破産を回避するAWS実践ガイド AWSアカウント(ルートアカウント)の保護 AWSアカウントが乗っ取られると詰むので、真っ先にセキュリティを強化する。 AWSアカウントへ二段階認証を導入 AWSアカウントでのログインは、AWSアカウント作成時のメールアドレス・パスワードだけでできてしまう。心許ないにもほどがあるので、まずは二段階認証を設定しよう。 IAMのページを開く https://console.aws.amazon.com/iam/home 「ルートアカウントのMFAを有効化」を選択して、「MFAの管理」ボタンをクリック 「仮想MFAデバイス」にチェックが入っていることを確認し、「次のステップ」ボタンをクリック 注意書きを読ん

                                                                    AWSアカウントを取得したら速攻でやっておくべき初期設定まとめ - Qiita
                                                                  • Googleは巨大なインフラをどうやってセキュアに保っているか。独自のセキュリティチップ利用やDoS対策、安全なソフトウェア開発など、全体像を解説したホワイトペーパーを公開

                                                                    Googleのクラウドは間違いなく世界最大規模のコンピュータシステムです。膨大なハードウェアとソフトウェアから構成されるこの巨大なシステムを、同社はどうやってセキュアに保っているのか。そのことを解説したホワイトペーパー「Google Infrastructure Security Design Overview」が公開されました。 ホワイトペーパーには、Googleのデータセンターを構成するデバイスの1つ1つにまで独自のセキュリティチップを組み込んで正規のデバイスかどうかを相互に認証するという物理レベルのセキュリティから、何層のものロードバランサーからの情報を集約してDos攻撃を検知すると、その通信を破棄するといったDoS対策。 そしてマシンも従業員もサービスも包括するグローバルな名前空間など、きわめて広範かつ綿密なセキュリティ施策が説明されています。 クラウドがいかに高度なセキュリティで

                                                                      Googleは巨大なインフラをどうやってセキュアに保っているか。独自のセキュリティチップ利用やDoS対策、安全なソフトウェア開発など、全体像を解説したホワイトペーパーを公開
                                                                    • セキュリティエンジニアを3年続けて分かったおすすめ勉強法

                                                                      セキュリティエンジニアとして就職してからそろそろ3年経ちます。独断と偏見に基づき、IT初心者・セキュリティ初心者・セキュリティエンジニアの3つの時期に分け、費用対効果の良い勉強法を紹介していきたいと思います。 セキュリティエンジニアとは 「セキュリティエンジニア」という言葉は範囲が広いですが、私が今回記載する内容は脆弱性診断やペネトレーションテストに寄った内容となっています。インシデント対応やアナリスト業務などは専門ではないので、あくまで診断系の人が書いているということをご認識おきください。 そもそもセキュリティエンジニアにどのような職種が含まれるかはラックさんが分かりやすい資料を出しているのでそちらをご覧ください(サイバーセキュリティ仕事ファイル 1、サイバーセキュリティ仕事ファイル 2)。 IT初心者時代 セキュリティを学ぶ以前に基礎となるITを学ぶ時代を考えます。 学校教育 学生の場

                                                                      • 「バックエンドの経験はなかった」Instagram創業者は、どうやってシステムをスケールさせてきたか

                                                                        昨日のPinterestの記事「Pinterestの急成長を支えてきたアーキテクチャとは? Pythonで開発しAmazonクラウドで運用」に続いて、やはり写真を中心としたサービスで急成長してきたInstagramのスケーラビリティについて、まとめてみました。 InstagramもPinterestと同様に、基本はAmazonクラウド上でPythonとフレームワークのDjangoを使ったシステムを構築しています。興味深いのは、創業者の二人ともバックエンドの経験がないなかで試行錯誤をしてシステムをスケールさせてきた点です。 Instagramは先月、Facebookに買収されると発表されています。この先、Instagramのシステムはどう変わっていくのでしょうか。 Instagramのシステム構成 約半年前、昨年12月にInstagramのブログに投稿された記事「What Powers In

                                                                          「バックエンドの経験はなかった」Instagram創業者は、どうやってシステムをスケールさせてきたか
                                                                        • AWSアカウントを作ったら最初にやるべきこと 〜2021年版〜 #devio2021 | DevelopersIO

                                                                          ログ・モニタリングのやるべきこと AWS CloudTrail の設定 CloudTrail は AWS リソースを「誰が」「いつ」「何に」対して「どうような」操作をしたのかを記録するサービスです。 ログの長期保管の設定をしておくことで、トラブル発生時の解析等に利用できます。 有料です(無料利用枠もあります) [YouTube] AWS CloudTrailを触ってみた CloudTrail Insights を利用することで、機械学習により異常なアクティビティを検出することもできます。 ログは S3 と CloudWatch Logs に転送でき、S3 に保管しているログは Athena により検索することもできます。 Athena を利用する場合は、事前に CloudTrail 用のテーブルを作成しておき、検索方法を習熟しておきましょう。 インシデントが発生してから習熟では対応が遅くな

                                                                            AWSアカウントを作ったら最初にやるべきこと 〜2021年版〜 #devio2021 | DevelopersIO
                                                                          • 世界各地で発生したランサムウェア WannaCry の感染事案についてまとめてみた - piyolog

                                                                            2017年5月12日頃から、世界各地でランサムウェアに感染する被害が相次いで報告されています。ランサムウェアはWannaCry等と名前が付けられているもので、これに感染する原因として、Windowsの脆弱性、及びその脆弱性を用いたNSAが開発したツールが関係している可能性があると各国のCSIRTやセキュリティベンダが注意喚起等を公開しています。Microsoftは今回の感染事案を受け、WindowsXPなどのサポートが切れたOSを対象とした緊急の更新プログラムも公開しました。 ここではこの世界中で発生したランサムウェア WannaCry の感染被害などについてまとめます。 インシデントタイムライン 以下は主に国内の関連事象を整理したもの。 日時 出来事 2016年9月16日 MicrosoftがSMBv1の使用停止を強く推奨する記事を公開。 2017年1月16日 US-CERTがSMBv1

                                                                              世界各地で発生したランサムウェア WannaCry の感染事案についてまとめてみた - piyolog
                                                                            • 「ミスを罰する」より効果的にミスを減らす『失敗ゼロからの脱却』

                                                                              ミスや失敗をなくすため、ヒューマンエラーに厳罰を下すとどうなるか? 一つの事例が、2001年に起きた旅客機のニアミス事故だ。羽田発のJAL907便と、韓国発のJAL958便が駿河湾上空でニアミスを起こしたもの。幸いにも死者は無かったものの、多数の重軽傷者が出ており、一歩間違えれば航空史上最悪の結果を招いた可能性もあった。 事故の原因は航空管制官による「便名の言い間違い」にあるとし、指示をした管制官と訓練生の2名が刑事事件に問われることになる。裁判は最高裁まで行われ、最終的には2名とも有罪となり、失職する。判決文にこうある。 そもそも、被告人両名が航空管制官として緊張感をもって、意識を集中して仕事をしていれば、起こり得なかった事態である [Wikipedia:日本航空機駿河湾上空ニアミス事故] より 芳賀繁『失敗ゼロからの脱却』は、これに異を唱える。 事故は単一の人間のミスにより発生するので

                                                                                「ミスを罰する」より効果的にミスを減らす『失敗ゼロからの脱却』
                                                                              • セキュリティエンジニアが本気でオススメする開発者向けコンテンツ 20選 - Flatt Security Blog

                                                                                画像出典: 書籍...記事中に掲載した販売ページ / Webサイト...スクリーンショット はじめに こんにちは。株式会社Flatt Securityの @toyojuni です。 突然ですが、弊社Flatt Securityは「開発者に寄り添ったセキュリティ」を標榜しています。Webアプリケーションなどに脆弱性がないか調査する 「セキュリティ診断」 においても、セキュアコーディング学習プラットフォーム 「KENRO」 においても、いかに開発者フレンドリーなサービスを提供できるかという点を大事にしています。 そんな弊社はお客様からさまざまな開発におけるセキュリティのアドバイスを求められることも多いのですが、その中で「開発に役に立つセキュリティ」という切り口では、なかなかまとまっているリファレンス集がないという課題に気付かされました。 そこで、社内でアンケートを実施して「開発者にオススメのセ

                                                                                  セキュリティエンジニアが本気でオススメする開発者向けコンテンツ 20選 - Flatt Security Blog
                                                                                • ITに強いはずのハイテク企業で、1億人超の個人情報が流出…… 「新技術こそ優れている」という思い込みが招いた大規模事件

                                                                                  連日さまざまなサイバーセキュリティ犯罪のニュースが報じられる中、いまだに日本のセキュリティレベルは高いとは言えない状況にあります。一方で、企業がサイバーセキュリティ対策を進める上では、人材不足や経営層の意識・関心、コスト、導入による利便性の低下など、さまざまな壁が立ちはだかっています。 そこで今回は、株式会社網屋が主催する「Security BLAZE 2023」より、サイバーセキュリティのエキスパートによる講演をお届けします。本記事では、米金融大手で1億人以上の個人情報が漏えいした事件の背景をひもときながら、問題点とセキュリティ対策のポイントを解説します。 Webセキュリティの第一人者が語る、個人情報流出事件の裏側 徳丸浩氏:ただいまご紹介いただきました、EGセキュアソリューションズの徳丸でございます。本日は「米国金融機関を襲った個人情報大規模流出事件の真相」というテーマでお話をさせてい

                                                                                    ITに強いはずのハイテク企業で、1億人超の個人情報が流出…… 「新技術こそ優れている」という思い込みが招いた大規模事件