「ソフトウェア脆弱性関連情報管理シート」を公開しました。社内で利用しているソフトウェアの情報と公表された脆弱性情報を一元管理するためのツールで、「どのレベルの脆弱性ならいつまでに対策する」といった社内ルールを決め、対策を実施するのにお役立ていただけます。
ipa.go.jp/security/techn…
ipa.go.jp/security/techn…
バックアップ
【転載】IPAが「ソフトウェア脆弱性関連情報管理シート」を公開。社内で利用しているソフトウェアの情報と公表された脆弱性情報を一元管理するためのツールで、「どのレベルの脆弱性ならいつまでに対策する」といった社内ルールを決め、対策を実施するのにお役立ていただけます。
バックアップ
【転載】トランプ大統領のパスワード
トランプ大統領は大統領選挙での劣勢が伝えられていますが、逆転に向けてこの脇の甘さが問題となるかも知れません。
オランダのセキュリティ専門家が、トランプ大統領のTwitter（ツイッター）アカウント、@realDonaldTrumpのパスワードを推測してアクセスすることに成功したという。パスワードは「maga2020!」だった（パスワードはすでに変更されている）。
GDI Foundationのセキュリティ研究者でセキュリティ脆弱性を見つけて報告するDutch Institute for Vulnerability Disclosure（オランダ脆弱性公表機関）の代表を務めるVictor Gevers（ビクター・ゲバーズ）氏はTechCrunchに、大統領のアカウントパスワードを推測し、5回目の試みで成功したと語った。
アカウントは2段階認証で保護されていなかったため、ゲバーズ氏のアクセスを許してしまった。
（Tech Crunch記事より引用）
キタきつねの所感
ホワイトハッカーによる疑似ハッキングは、ホワイトハウスの副報道官は「まったく真実でない」と否定していますが、大統領のSNSセキュリティのコメントを拒否した様ですので、疑似ハッキングは成功してしまったのかと思います。
とは言え、大統領選の終盤のこの時期にこうした「ニュース」をぶつけてくる事に、何かの”意図”を感じなくもありません。
それはさておき、仮にこの件が本当だったとして、ホワイトハッカーに突破されたパスワードは、何故5回の試行で破られてしまったのでしょうか？少し真面目に漏えいしたとされる、パスワード強度を考えてみます。
「maga2020!」
パスワードの構成上は、英小文字、数字、記号が使われており、パスワード長は9文字とまずまずの長さです。しかし、”2020”と”！”はパスワード保有者にとってユニーク（特有なもの）とは言えません。
”2020”は誰でも「今年」の事を指す事は分かると思いますので、パスワード桁数を増やす事には貢献しても、構成要素とては弱いかと思います。記号の”！”もユニークではありませんので、このパスワードの肝となるのは、【maga】となる事は明らかです。
この単語・・・どこかで見覚えがあるなと思った貴方！正解です。
『Make America Great Again』の頭文字以外の何物でもありません。
Bestmaple ドナルドトランプ 帽子 キャップ Make America Great Again Hat Donald Trump アメリカ国旗 ベースボールキャップ
- メディア: ウェア&シューズ
そりゃ・・・パスワード破られても不思議ではないですね。
（ホワイト）ハッカーは、攻撃をする際に、対象者（トランプ大統領）のSNS等から情報を拾い、例えば誕生日であるとか、ペットの犬の名前であるとか、今回の様に『選挙キャンペーンフレーズ』をパスワード候補として攻撃してきます。
今回の【maga】は、「容易に推測できるパスワード」（の一部）だったと言えるのです。
とは言え、このパスワード（mage2020!)、強度がすごく弱いという訳ではありません。仮に、大統領選の対立候補であるバイデン氏が使っていたとしたら、ホワイトハッカーは恐らく破れなかったと思います。
参考まで、パスワードチェッカーとして有名な「How Secure Is My Password?」では、16時間で解読されるとの評価です。
同じく、パスワードチェッカーとして評価が高い「Kaspersky Password Checker」では、28日の評価結果です。
もう１つ。過去の漏えい事件で流出したパスワードかどうか分かる「Pwned Passwords」では、驚くべき事に『流出したという事実が無い』と評価されました。
私でしたらどうやってトランプ大統領のパスワードをベースを変えずに強化するか、と考えると・・・
単純な手法としては、記号を増やします。(最初に入れると見破られそうですが）これだけでも意外とホワイトハッカーの攻撃は凌げたと思います。
例）『maga20!20!』『ma#ga2020!』
記号を２つ使うと（その記号を置く位置も併せて）試行すべき組み合わせが膨大に増えますので、ハッカー側は結構大変かと思います。単語（magaや2020）の間に挟むとより複雑性が増しますのでオススメです。
もう１つの手法として、（私のオリジナルという訳ではありませんが）、他の要素と関係性の無い単語を増やします。
例）『mage2020!JAPAN』『mage2020!yankees』
日本やニューヨークヤンキース（出来ればファンでない所が望ましい）といった、選挙やトランプ大統領とあまり関係が無く、SNS上でも出てこない単語（※ここが重要です）が１つ入っただけで、例えツール攻撃したとしても、ハッカーがパスワード解読にかかる時間は膨大なものとなるかと思います。
トランプ大統領アカウントのハッキング、事実だとすれば、非常に重要なTwitterアカウントであるが故に（下手な事をつぶやくと国際問題や世界の株価に大きく影響する）、大統領や大統領陣営はもっとSNSのセキュリティにも気を遣うべきだったかと思います。もし何でしたら酒席セキュリティ担当として雇って下さい。
とは言え、パスワード強化よりも先に『2要素認証』を設定すべきだとは思いますが。
※どこがオリジナルか分からないのですが、複数の関係ない単語を使った強力なパスワード作成手法について、英語圏で広く出回っている説明イラストを参考まで貼っておきます。
余談です。日本だとオランダのセキュリティ専門家（ホワイトハッカー）の『疑似ハッキング』行為は、不正アクセス禁止法（3年以下の懲役または100万円以下の罰金）に引っかかります。
その事自体は当然の事とは思いますが、私は認められたホワイトハッカー企業や個人に、制約付きで同様な脆弱性調査を認めるべきでないかと思います。
【転載】コインチェックのインシデント対応レポート～AWSのイメージが良くなり、ドメインレジストラのイメージ悪化～
2020年6月、仮想通貨取引所「Coincheck」を運営するコインチェックのコーポレートサイトに、あるセキュリティインシデントの報告書が掲載された。当時、重要な事例として筆者のセキュリティ連載「半径300メートルのIT」でも取り上げたことから、記憶に残っている読者もいるのではないだろうか。
インシデントのあらましを簡単に説明しよう。これは、コインチェックが利用する外部のドメイン登録サービスにおいて、コインチェックのネームサーバ（DNS）情報が、何者かに書き換えられたものだ。これにより、同社のドメインのレコードが偽のDNSに登録され、同社にメールで問い合わせた顧客のメールアドレスと本文が第三者に流出する可能性があった。コインチェックはインシデント発生後、対応についてのレポートを公開するとともに、利用するドメイン登録サービスを変更したと発表した。
このインシデントは、一般に「不正アクセス」という言葉から連想する事件とは異なり、一見地味な印象を受けてもおかしくないものだ。しかし、報告書には、セキュリティ担当者ならば誰でも青ざめるような展開が赤裸々につづられていた。
ITmedia エンタープライズ編集部は、実際に同社でインシデント対応に当たった喜屋武 慶大氏（サイバーセキュリティ推進部長）に講演を依頼。2020年9月に開催したオンラインイベント「ITmedia Security Week 秋 - ITmedia エンタープライズ」の特別講演として、当時の様子を当事者の目線で振りかえってもらった。その内容は、セキュリティ担当者だけでなく組織でITに関わる人ならば誰もが非常に参考になるものだった。本稿は喜屋武氏の講演の内容をレポートする（注）。
注：本稿はITmedia エンタープライズ主催「ITmedia Security Week 秋」の講演「ドメインが乗っ取られた！！そのとき我々はどう対応したか」を基に再構成した。
読者の皆さんには「自分がもしもセキュリティ担当者なら、気付くことができただろうか」と問いかけながら、目を通していただきたい。
2020年6月1日正午ごろ：「何かがおかしい」という報告から全てが始まった
その日（インシデント発生当日）、最初に違和感に気付いたのは、社内のSRE（Site Reliability Engineering：サイト信頼性エンジニアリング）チームだった。
「ITmedia Security Week 秋 - ITmedia エンタープライズ」に登壇し、インシデント対応の様子を語ったコインチェックの喜屋武 慶大氏（サイバーセキュリティ推進部長）2020年6月1日正午ごろ、コインチェックで通常の監視業務に当たっていたSREチームは、普段と異なる状況を察知した。前日に比べて自社サービスに対するリクエスト数が異常に少なかったのだ。
「『何かがおかしい。怖い』という報告が、SREチームから社内で使う『Slack』のワークスペースに上がってきた。それが発端だった」（喜屋武氏）
SREチームはまず、リクエスト数の激減以外にも何か異常がないかどうかをチェックした。すると、前日の5月31日を境にサービスのレスポンスタイムが遅延していることが分かった。「この時点では誰もDNSの書き換えという結論は想像していなかった」と喜屋武氏は振り返る。
「Slackでのやりとりをはた目で見ながら『何か障害でも起きたのだろう、あとで共有してもらえばいい』と思っていた」（喜屋武氏）
この違和感をきっかけに、SREチームは本格的な調査に乗り出した。しかし原因はなかなか見つからない。アプリケーションには異常がなく、サーバもロードバランサーも問題がないように見える。ただし、喜屋武氏によれば、ユーザーの感覚としては普段と変わらないように見えても、モニタリングダッシュボードに示されるレスポンスタイムはどんどん遅延していったという。リクエスト数は減っているにもかかわらずだ。
6月1日午後：レスポンス遅延が悪化 「障害ではなく、攻撃だ」と気付いたきっかけ
6月1日の午後になると、レスポンス遅延はさらに進み、体感で分かるレベルになってしまった。また、全ての社員ではなく、特定のメンバーに限ってレスポンス遅延が発生していることも分かってきたという。
原因を突き止めようと、SREチームは、遅延が確認できた環境から経路を確認するtracerouteコマンドを実行した。すると、通常ならば数ホップで同社が利用する国内のAmazon Web Services（AWS）まで到達するはずのリクエストが、なぜかアムステルダム（オランダ）のリージョンにあるAWSのCDN（Content Delivery Network）サービス「Amazon CloudFront」を経由していた。
これこそがレスポンスの遅延の原因と思われたが、そもそもなぜリクエストがオランダを経由するのかが分からない――。不審に思った喜屋武氏は、AWSのサポートに連絡を取った。コインチェックがインシデント対応に奔走する“長い夜”は、この時点で既に始まっていた。
喜屋武氏が「権威DNSに何か問題があるのでは」とAWSのサポートに確認したところ、返ってきた答えは「これはAWSのDNSではない」だった。同氏はその際の反応について「『えっ！』と驚くしかなかった」と話す。このやりとりをきっかけに、AWSのCDN（Content Delivery Network）サービス「ns-1515.awsdns-61.org」に0を足して「ns-1515.awsdns-061.org」にすり替える、一見しただけでは気付かないような手口だった。
この時点からインシデントが一段落するまで、SREチームはAWSのサポートとのやりとりを重ねることになった。
「（違和感に気付いた当初は）ひょっとしたらAWSの障害が原因ではないかと思って問い合わせたことをきっかけに、結果として別の原因が判明した。しかし、その後もAWSのサポートは（インシデント対応に）付き合ってくれた。こういうときに素早く反応してもらえたので、サポート契約していて良かったと感じている」（喜屋武氏）
2020年6月1日夕方：レジストラが乗っ取られていたことが判明
6月1日夕方ごろ、本格的なインシデント対応が始まった。まずは、システム担当の執行役員に対して、これまでのいきさつを報告した。また、状況報告に使うコミュニケーションツールをSlackからWeb会議サービス「Zoom」に切り替えた。「Zoomが詰め所のような形になり、そこに参加する形で執行役員に指揮を執ってもらった」と、喜屋武氏は語る。
状況を報告されたシステム担当の執行役員は、想定しない報告に当初「えっ！」と驚くのみだった。後日、役員は喜屋武氏に「重めのシステム障害を想定していたため（サイバー攻撃を受けたと報告が来た際は）何を言われているのかさっぱり分からなかった」と明かした。
DNSが改ざんされたと分かった以上、初動対応として、コインチェック側はレジストラにログインし、DNSを元に戻そうとした。しかし、IDとパスワードを使ってもログインできない。パスワードをリセットしようとすると、今度はリセットのためのメールがコインチェックに届かない――。つまり、この時点で、レジストラのIDは完全に乗っ取られてしまっていた。
喜屋武氏がドメイン名を検索して状況を確認すると、日本時間で5月31日の深夜にDNSレコードがアップデートされていた。もちろん、コインチェック社内でその時間に当該の操作をした者はいなかった。5月31日深夜を境にレジストラの登録情報が乗っ取られ「coincheck.com」が奪われてしまった。コインチェックがこの事実を把握したのは、6月1日の19時過ぎだった。
タイミングの悪いことに、新型コロナウイルス感染症（COVID-19）の影響でレジストラの電話サポートなどが縮小されていた。コインチェックはレジストラにメールで対応を依頼したが、その時点でレジストラの営業時間外だったため、最悪対応が翌日になってしまうことも考えられた。このタイミングで、コインチェックは社外のセキュリティアドバイザー2人にも状況を報告し、インシデント対応に参加してもらうことになった。
2020年6月1日夜：なぜ、どうやって攻撃された？ 長い捜索が始まる
DNSが不正に書き換えられてしまった場合、それを元に戻せるのはレジストラだけだ。レジストラの対応を待つ間、コインチェックは、今回のインシデントの根本原因を探る調査を開始した。
この時、真っ先に疑われたのはマルウェア感染による不正アクセスだった。しかし、喜屋武氏がログを確認したところ、社内の端末にマルウェア感染は確認できなかった。不審なアクティビティーがないかどうか、未知のマルウェア攻撃がある前提で調査を継続したが、エンドポイントからのアラートも上がっていない。操作ログや通信ログ、プロセスログにも、それらしい痕跡はなかった。喜屋武氏は「マルウェア攻撃が原因である可能性は低い」と判断し、次の調査に移ることにした。
マルウェア以外に、アカウント乗っ取りやパスワードクラック、セッションハイジャックなどが原因になっている可能性もあった。このうち、アカウント乗っ取りが発生していれば、他のサービスを攻撃されている可能性も高い。しかし、シングルサインオン（SSO）ログやSaaSのログイン履歴に不審な点はなかった。セッションハイジャックの可能性も低かった。レジストラに最後にログインした日時がかなり前であり、5月31日時点では有効ではないことが確認できたためだ。
「パスワードに関しては、サービスで設定できる最長の文字数を、パスワードジェネレーターで生成している。それなりの強さであり、総当たりでパスワードクラックを行うことは不可能。使い回しもしていない」（喜屋武氏）
残された可能性は、レジストラの脆弱（ぜいじゃく）性だった。調査に参加したセキュリティアドバイザーからは「海外でもレジストラの脆弱性をきっかけとした攻撃が発生している」というコメントを得ていた。この時点では可能性の一つでしかなかったが「結果的には、レジストラの脆弱性が原因だった」と、喜屋武氏は話す。
「もしレジストラの脆弱性が原因だったなら、（他の事業者も対象にした）攻撃キャンペーンがあるはずだと考えたが、当社以外に攻撃されているという情報がなかった。念のためレジストラにログインした端末は隔離し、他のサービスにもサインオンできないようにした」（喜屋武氏）
調査が進む中、2020年6月1日20時52分ごろ、レジストラから「DNSの情報を元に戻した」という連絡が来た。この時点で、コインチェックではシステム担当執行役員から社長にインシデント発生の報告を上げていた。同社は社内で制定済みの対応フローに従い、緊急事態対策本部を設置した。
2020年6月1日深夜：ドメインがついに回復 判明した衝撃の手口とは
DNSは元に戻ったものの、この時点では、インシデントが社内やユーザーを含めてどの程度の範囲に影響を与えたのか、明確に見えていなかった。影響範囲の確認を兼ねて調査を続けていると、DNSに不審なMXレコードが設定されていることが判明した。攻撃者は、コインチェックのメール情報を盗もうとしていたのだ。
「不正に設定されたIPアドレスを確認すると、coincheck.comを返すメールサーバが動いていた。しかし、SPFレコードの設定が書き換えられていなかったため、coincheck.comを送信元とするメールを送信することが狙いではなさそうだった」（喜屋武氏）
この動きを確認した時点で、時刻は6月2日の深夜1時を過ぎようとしていた。DNSは無事に取り戻せたが、インシデントを引き起こした攻撃の詳細や原因はまだ分かっていなかった。この状況では、攻撃者が再びDNSを改ざんできてしまう可能性もある。喜屋武氏は自分とSREチームの1人を残して他のメンバーを解散させ、2人体制の監視に入った。そして、全社員のメールボックスをくまなくチェックし始めた。
すると、重大な事実が見えてきた。複数の社員のメールボックスの中に「GitHub」をはじめとする複数のサービスからパスワードリセットのメールが大量に届いていたのだ。該当の社員にヒアリングしたところ、彼らは一様に「パスワードをリセットするような操作はしていない」と答えた。実際に、喜屋武氏は社員の操作履歴を精査し、成功したパスワードリセットのリクエストがなかったことを確認した。
ここまでの状況から、初めて攻撃の全体像が見えてくる。
「レジストラの情報を書き換えることで、攻撃者が用意したサーバに問い合わせさせ、偽のレコードを引いてくる。これにより、攻撃者がcoincheck.comに届くメールを不正に取得した」（喜屋武氏）
攻撃者はDNSを直接攻撃せずに、レジストラを攻撃することでDNSを乗っ取ったのだ。
2020年6月2日：プレスリリース第一報を公開、そして……
翌日の6月2日、コインチェックは、朝、昼、夕方の定期Webミーティングを設定した。Web会議には指揮官であるシステム担当の執行役員に常にオンライン状態でいてもらい、進捗（しんちょく）を報告した。Web会議を対策本部にするスタイルはあくまでもCOVID-19対策だったが、これが意外な効果を生んだ。
「リアルな会議室でホワイトボードを前にするようなこれまでの会議スタイルとは異なり、Web会議なら作業をしながらでも報告ができる。そこに入れば誰かがいて、助言をもらえる。振りかえると、この体制はとてもやりやすく、メンバーのから評判も良かった」（喜屋武氏）
ユーザーのサポート窓口となるメールアドレスで利用しているドメインは、すでに攻撃の対象となっていた。ユーザーへの悪影響を防ぐため、コインチェックは新たに「coincheck.jp」のメールアドレスを設定し、動作を確認した上で、インシデントについて記したプレスリリースを公開した。その後の展開は、ITmedia エンタープライズやその他の報道で皆さんもご存じのことだろう。
被害を増やさないために――担当者が語る予防策
喜屋武氏は今回のインシデントを振り返り「本物に酷似したドメイン名をDNSに設定されてしまう攻撃例は、知る限り世界初ではないか」と話す。この攻撃の恐ろしい点は、いったんドメインを乗っ取られ、MXレコードを書き換えられてしまうと、自分が正規のユーザーであることを証明する手段がほとんどなくなってしまうところだ。このような手口は、社内で使うサービスのパスワードがメールを使ってリセットされる設計の弱みを突いたようにも見える。
視聴者に向けたメッセージとして、喜屋武氏は「（今回のインシデントからは）ドメイン乗っ取りの被害が甚大であることを確認できた。DNSはとても大事なサービスだ。このインシデントを参考にし、レジストラに登録したDNSの設定はしっかり監視してほしい。また、権威DNSに使っている関連サービスのアカウント管理情報やレコードは定期的にチェックしてほしい」と話し、講演を締めくくった。
サイバー保険でインシデント対応の費用が賄えるのか？
1つ目が、サイバー保険を付帯した標的型攻撃メール訓練のニュースで、インシデント費用を最大600万円補償するというもの。
2つ目は、インシデント発生時における対応費用の実態が約1.5億円となっているというもの。
1件目のサイバー保険を付帯した標的型攻撃メール訓練で、インシデント対応費用が最大600万円で全然足りないのは何となく理解できる。
グリコのおまけ的な扱いであることを認識していれるか、とりあえず「サイバー保険導入」の事実を成立させたい組織には向いているが、リスクファイナンスを真剣に考えるとあり得ない選択だと思う。
サイバー保険を付帯した標的型攻撃メール訓練をOEM供給:
ラックは、パートナー向けにサイバー保険を付帯したトレーニングサービス「サイバー保険付き標的型攻撃メール訓練 プレミアム」を提供開始した。
同製品は、疑似的な標的型攻撃メールを従業員へ送付する体験学習型の訓練プログラム「ITセキュリティ予防接種」にサイバー保険を付帯したもの。
同社の販売パートナーチャネル向けにOEM供給し、パートナーは自社製品やサービスに組み込んだり、オリジナルサービスとして販売することができる。
損害保険ジャパンを引き受け保険会社とするサイバー保険を付帯。訓練を実施した企業において、サイバー攻撃に関する調査費用をはじめ、復旧や再構築費用、損害賠償金について最大600万円まで補償する。
■記事2
同製品は、疑似的な標的型攻撃メールを従業員へ送付する体験学習型の訓練プログラム「ITセキュリティ予防接種」にサイバー保険を付帯したもの。
同社の販売パートナーチャネル向けにOEM供給し、パートナーは自社製品やサービスに組み込んだり、オリジナルサービスとして販売することができる。
損害保険ジャパンを引き受け保険会社とするサイバー保険を付帯。訓練を実施した企業において、サイバー攻撃に関する調査費用をはじめ、復旧や再構築費用、損害賠償金について最大600万円まで補償する。
■記事2
約4割でインシデント被害、対応費用は約1.5億円 - 4.4％が「Emotet」経験:
国内法人における約4割のセキュリティ担当者が、セキュリティインシデントに起因する被害を経験したとする調査結果をトレンドマイクロが取りまとめた。被害への対応や改善策の導入などで約1億4800万円の費用が生じていたという。
同社が6月に国内法人においてインシデント状況を把握しているリスク管理、ITシステム、情報セキュリティなどの担当者1086人を対象にインターネット調査を実施し、結果を取りまとめたもの。所属組織の内訳を見ると民間企業が980人、官公庁自治体が106人となっている。
2019年4月から2020年3月の1年間に被害の有無に関係なく、何かしらのインシデントを経験した回答者は78.5％だった。インシデントの内容を見ると、「フィッシングメールの受信」が42.8％でもっとも多い。
ついで「ビジネスメール詐欺のメール受信」が29.1％と多く、「不正サイトへのアクセス（26.5％）」「標的型攻撃（22.2％）」「ランサムウェア感染（17.7％）」と続いた。
約1割で「DDoS攻撃」「内部不正」が発生していたほか、「システムの脆弱性の悪用（11.4％）」や「システムの設定ミスの悪用（7.6％）」などシステムの問題を突く攻撃なども見られる。さらに4.4％は、マルウェア「Emotet」を経験していた。一方、21.5％はインシデントが発生していないと回答している。
【転載】イミュータブルインフラストラクチャとは？
【解説】
「イミュータブル」とは「変更不可能な」という意味で、言い換えると「一度作成したら、その状態を変えることができない」と表現することもできます。反対語は「ミュータブル (変更可能な)」となります。
現実世界の例を出してみましょう。例えば「重要な書類を書く場面」を想像してみるのはいかがでしょうか ? ボールペンで書類を書くことを「イミュータブル (変更不可能な)」だとすると、鉛筆で書類を書くことを「ミュータブル (変更可能な)」と考えることができます。
【メリット】
1. 書類を書き換えられなくなる
ボールペンで書類を書くことにより、書類を書き換えられなくなるというメリットがあります。重要な書類のほとんどはボールペンで書くことにより、書いた内容を保証しています。これは「一度書いた書類の状態を変えることができない」と言い換えることもできます。提出した重要な書類を勝手に書き換えられてしまったら困ります。
2. 書類が汚れない
例えば、住所を書き間違えてしまうこともあります。そのときに鉛筆で書類を書いていれば、繰り返し書き換えられるため便利に感じるかもしれません。しかし、実際には消しゴムを使って消すことになります。消そうと思っても「キレイに消えなかったり」、消えるには消えたけど「消しカスが大量に出てしまったり」、繰り返し書き換えることにより、書類が汚れてしまいます。書き換えによって書類が汚れないという点もメリットの 1 つと言えます。
【まとめ】
本記事では、重要な書類を書く場面を比喩に「イミュータブル」を紹介しました。実際のワークロードでは、例えば Amazon EC2 インスタンスを「イミュータブル」に運用し、修正をする場合には新しくインスタンスを作り直せる仕組み作りが重要です。
【所感】
イミューダブルインストラクチャとは、インフラ（OS、ミドルウェア）へのパッチ適用は一切行わず、脆弱性が見つかったら、脆弱性対策が行われた最新版のインスタンスに移ることで脆弱性対策を行うということである。
つぎはぎでパッチ適用を行う事が将来的なシステムの安定化に危害を及ぼすという考え方で、IaaSならではの発想である。
実際はOSやミドルのバージョンが変わっちゃうとその上のアプリも影響を受けてしまうため、運用工数といった観点では地道にパッチ適用するのと変わらない気がする。
ただ、脆弱性対策の観点でこのようなアプローチがあるというのはとても勉強になった。
【参考】
https://aws.amazon.com/jp/builders-flash/202005/metaphor-immutable/
【転載】IT技術用語における「疎結合」とは？
【例文】
アプリケーションを「疎結合」にする
マイクロサービスは「疎結合」な特性を持っている
【解説】
「疎結合」とは「結合度を緩める」という意味で、言い換えると「独立性を高める」と表現することもできます。反対語は「密結合」となります。
現実世界の例を出してみましょう。例えば「年賀状など、手紙を送る場面」を想像してみるのはいかがでしょうか ? 手紙を郵便ポストに投函することを「疎結合」だとすると、郵便局で配達員に直接手渡しすることを「密結合」と考えることができます。
【メリット】
では、現実世界の例をさらに深堀り、メリットを考えましょう。
1. 郵便局の営業時間を気にせずに手紙を送れる
郵便ポストに投函することにより，郵便局の営業時間を気にせずに手紙を送れるというメリットがあります (24 時間営業ではないという前提とします)。郵便ポストさえあれば、好きなときに投函できますよね ! これは「手紙を送ること」と「配達をすること」の「結合度を緩めている」と考えることもできます。
2. たくさんの手紙を投函できる
年賀状の時期など、たくさんの手紙を送る場面もあるでしょう。もし郵便局で配達員に直接手渡しをしてしまうと、もしかしたら配達員の手が回らなくなってしまう可能性もあります。さらに受付に順番待ちができてしまうかもしれません。郵便ポストさえあれば、たくさんの手紙も投函しておくことができます。これも「結合度を緩めている」からこそ得られるメリットと考えることができます。
3. 定期的に回収できる
配達員の視点で考えると、手紙を直接手渡しで受け取るよりも、好きなタイミングに郵便ポストから回収できた方が柔軟です。「結合度を緩めている」からこそ、配達員の「独立性を高められている」と考えることができます。
【まとめ】
実際のワークロードでは「レポート生成処理」や「画像変換処理」において「疎結合」を意識すると良いでしょう。AWS では、例えば Amazon SQS を活用した「疎結合アーキテクチャ」を構築することができます。アプリケーション A と アプリケーション B の「結合度を緩める」というイメージです。
【所感】
所謂3層構造と言われる、Web、アプリ、DBサーバをそれぞれ分離して構築することも「疎結合」の範疇に入る。
セキュリティ的な要素のイメージが強いが、システムの安定稼働（障害発生時の影響範囲を限定する）の観点でも意味のあるポイントと言える。
【参考】
https://aws.amazon.com/jp/builders-flash/202003/metaphor-loose-coupling/
【転載】できる人のGoogle検索テクニック
🧐やらないけどけど
できる人のGoogle検索テクニック
インターネットで何か調べようとするとき、まず「Google検索」、という人が多いのではないだろうか。中でも、単語を入力する、もしくは複数の単語をスペースを空けて入力して検索するだけという人が多いようだ。
実はGoogle検索には、「検索演算子」と呼ばれる、特殊な検索条件の指定方法があり、これらをうまく使うと、より効率的な検索も行える。他にも、知っておくと便利な検索テクニックが幾つかあるので、ここでまとめて紹介しよう。
検索演算子を使いこなそう
●「+」／「AND」で複数キーワードを含むWebページを検索
AND検索を行うのに、「スペース（空白文字）」を空けて複数キーワードを並べて検索、というのは、ごく普通に利用しているテクニックだろう。さらに明示的にAND検索をするには、キーワードを「+」または「AND」で追加していくとよい（「AND」は大文字にして、単語間にはスペースを空けること）。
例えば、「ITmedia AND ＠IT」といった具合に検索すると、両方のキーワードを含むWebページが検索対象となる。単に「スペース」を空けた場合と、「AND」で挟んだ場合では、同じAND検索のはずなのだが、検索結果が微妙に異なることがある。単にスペースを空けた検索でうまく絞り込めない場合は、「AND」を使ってみるとよい。
●「OR」でいずれかのキーワードが含まれているWebページを検索
Google検索では、検索キーワードの補完機能があるため、例えば大文字と小文字や平仮名と片仮名などは、どちらでも同じような検索結果が得られることが多い。例えば、「マイクロソフト」と「Microsoft」では、ほぼ同じような検索結果となる。そのため、わざわざ両方のキーワードを「OR」で並べるOR検索の必要性はそれほど高くないかもしれない。
ただ「ITmedia」と「＠IT」のように異なるキーワードのどちからを含むWebページを検索したいような場合、OR検索を使うと、両方の検索キーワードを検索した結果を合わせたものが得られる（「OR」は大文字で、キーワード間に「スペース」を空けること）。
●「-」で特定の検索キーワードを含まないWebページを検索
複数の検索キーワードのうちで、特定の検索キーワードを含まないような結果を得たい場合、除きたいキーワードの前に「-（半角マイナス）」を付けるとよい。
例えば、「マック」について調べたいが、「マクドナルド」については除外したいような場合、Googleの検索ボックスに「マック -マクドナルド」と入力すれば、「マック」の検索結果から、「マクドナルド」が含まれるWebページが除外されるため、1回で検索結果の絞り込みが行える。
●「*」で検索キーワードを補完して検索
人の名前や地名など、うろ覚えで正確に思い出せないような場合、検索キーワード内に「*（アスタリスク）」を挿入するとよい。アスタリスク（*）の部分が適当に補完されて検索が実行される。
●「"＜キーワード＞"」で複数語の完全一致検索
キーワードにスペースが含まれるような場合、そのまま検索してしまうと、上述の通り、AND検索になってしまい、思ったような検索結果が得られないことがある。
例えば、「Windows 10」を検索するような場合、そのまま検索すると「Windows」と「10」を含むWebページが検索結果として得られてしまい、「Windows 10」以外にも、「Windows」と「10年」といった「Windows 10」に関係ないWebページも対象となってしまう。
このような場合、キーワード全体を「"」で挟んで「"＜キーワード＞"」といったように検索すると、スペースを含む語句の「完全一致」で検索が行われる。
例えば、「"Windows 10"」として検索を行えば、「Windows 10」が完全一致で含まれるWebページが検索結果として得られる。ただし、「Windows 10」のような「メジャーなキーワード」は、Google検索側で適宜補完処理され、完全一致として優先して検索される。そのため、あえて「"」で挟まなくても、ほぼ同じ結果が得られるようだ。
●「@」でソーシャルメディアを検索する
Twitterやインスタグラムなど、ソーシャルメディアを情報の入手先とする人も多くなっている。そのためソーシャルメディアを優先した検索を行いたいという場合もあるだろう。そのような場合、検索キーワードの後にスペースを空けてから、ソーシャルメディアの名前の前に「@（半角アットマーク）」を付けて指定すると、そのソーシャルメディアが優先された検索が行われる。
例えば、「山手線 遅延 @twitter」と検索すると、山手線の遅延に関するTwitter上のツイートなどが優先されて検索される。同様に「@instagram」とすれば、インスタグラム上の画像なども検索可能だ。
意外と便利な特別構文検索
●「site:＜URL＞」でサイト指定の検索
「site:」は、すでに使っている人も多いだろう。 「site:」に続けてURLを指定すると、そのURLのサイトまたはドメイン内だけを対象とした検索が行われる。例えば「Windows site:http://www.atmarkit.co.jp/」と指定すると、＠ITサイト内だけで「Windows」というキーワードが検索される。特に、検索機能がないWebサイト内を検索する際に便利な機能だ。
●「cache:＜URL＞」でキャッシュに保存されたバージョンを表示
＜URL＞で指定されたWebページを、Googleに保存されたキャッシュの中から探して表示する。場合によっては、修正前のWebページや削除されたWebページを見ることができる。
●「link:＜URL＞」で被リンクを検索
＜URL＞で指定したバックリンク（被リンク）情報を表示する（指定された＜URL＞をリンク先として含むページを表示する）。リンク元ページは、サンプルで抽出されたごく一部だが、そのURLがどのページからリンクされているのか調べることができる。
●「intitle:＜検索キーワード＞」／「allintitle:＜複数の検索キーワード＞」でタイトルを対象に検索
Webページのタイトルを対象にキーワード検索を行う場合、「intitle:」を使うとよい。例えば、製品名などはWebページのタイトルとなっているケースが多いので、こうした製品紹介ページなどを検索するような場合は、「intitle:＜製品名＞」で検索すると、目的にWebページが見つかりやすいだろう。
「allintitle:」は、指定した複数の検索キーワードが全て含まれているWebページのタイトルの検索を行う。
●「inurl:＜検索キーワード＞」／「allinurl:＜複数の検索キーワード＞」でURLを対象に検索
URLを対象に指定したキーワード検索を行う場合、「inurl:」を使う。例えば、「Windows inurl:wiki」と検索すると、URLに「wiki」が含まれたWebページだけを対象に、「Windows」というキーワードで検索が行われる（「Windows」と「inurl:wiki」のAND検索が行われる）。特定のドメイン名の下のみを検索したいような場合に便利だ。
複数のキーワードが全て含まれたURLを対象したい場合は、「allinurl:」を使う。
●「intext:＜検索キーワード＞」／「allintext:＜複数の検索キーワード＞」で本文を対象に検索
Webページの「<body>タグ」～｢</body>タグ」で挟まれた本文のみを対象に、指定したキーワードで検索を行う。「intext:」は単一のキーワード、「allintext:」は複数のキーワードが全て含まれたWebページを表示する。「intext:」を使うと、本文以外の部分に、キーワードを埋め込んだSEO対策を行っているようなWebサイトを除外することができる。
●「inanchor:＜検索キーワード＞」／「allinanchor:＜複数の検索キーワード＞」でリンクを検索
「inanchor:」「allinanchor:」は、リンクのテキスト（いわゆるアンカーテキスト）に指定のキーワードが含まれているWebページを検索するのに用いる。例えば、自社のWebページのタイトルにリンクしているようなWebページを調べたいような場合、「inanchor:＜対象ページのタイトルテキスト＞」というように指定して検索してみるとよい。
●「related:＜URL＞」でサイトテーマが近いものを検索
「related:」は＜URL＞で指定したサイトとテーマが似たWebサイト（Webページ）を検索するのに用いる。例えば、「related:www.atmarkit.co.jp」と検索すると、IT系メディアのWebサイトが一覧表示される。自社と競合するWebページ（サイト）を調べる際などに利用できる。
●「filetype:＜ファイルタイプ＞」でPDFなどを対象に検索
「filetype:pdf」や「filetype:doc」などとすれば、PDFファイルやDOCファイルを対象とした検索が行われる。「pdf」「doc」「docx」「ppt」「pptx」などのファイルタイプを指定して検索できる。
●「info:＜URL＞」で指定したWebページの情報へのリンクを表示
＜URL＞で指定したWebページ（Webサイト）の「Googleに保存されているキャッシュ」「類似したページの検索」「ウェブページを検索」「含むページの検索」といった情報へのリンクが表示される。
Google検索の検索オプション／検索ツールを使おう
上述の検索演算子などは、検索時に指定して絞り込み検索を行うものだが、「検索オプション」や「検索ツール」を使うと、検索後に検索結果の絞り込みが行える。
●「検索オプション」を使う
以下のURLで「検索オプション」を開いて、必要な項目に入力して［詳細検索］ボタンをクリックすれば、上述の検索演算子を使ったのと同様の検索が行える。検索演算子を覚えてなくても、簡単に絞り込み検索が可能だ。
検索を実施後にGoogle検索のメニュー（検索入力ボックスの下）の［設定］－［検索オプション］を選ぶと、入力済みの検索キーワードが「すべてのキーワードを含む」に入力された状態で「検索オプション」が開く。さらに、他の項目を追加すればよい。
●「検索ツール」を使って結果を絞り込む
検索結果をWebページの公開された日付に基づいて検索結果で絞り込んだり、対象の言語（日本語環境のデフォルトは「すべての言語」と「英語と日本語のページを検索」の切り替え）や検索キーワードの「完全一致」などで絞り込んだりすることが可能だ。
なるべく新しい情報が記載されたWebページを見つけたいといった場合は、「24時間以内」「1週間以内」など期間を指定するとよい。
【転載】セキュリティ関連資格チャート表
【まとめ】セキュリティ資格の合格記・受験記:
先日、Ciscoの認定資格「CCNA」を受験してきまして、無事合格できました。
私にとっては1年半ぶりに新しく取得した資格であり、久しぶりに資格を取得する楽しさを味わうことができました。
私は資格勉強をする際によくその資格の合格記を読んでいます。
合格記は受験者の目線で書かれており、実際に行っていた勉強法や参考書・資料、役立ったことと逆に役立たなかったことを紹介しており、勉強のとっかかりや受験時期を決めるのにとても参考になります。
そこで、今回は私が受験予定・興味を持っている資格の合格記・受験記について参考になりそうな記事を各資格ごとにまとめてみました。
（情報は随時追加予定です）
【目次】
- CISSP(Certified Information Systems Security Professional)
- SSCP(Systems Security Certified Practitioner)
- OSCP(Offensive Security Certified Professional)
- CEH(Certified Ethical Hacker)
- おわりに
参考までにセキュリティの認定資格のチャート表が公開されていますので、リンクを貼っておきます。
CISSP(Certified Information Systems Security Professional)
CISSPは(ISC)² が認定を行っているセキュリティの国際資格です。SSCP(Systems Security Certified Practitioner)
SSCPはCISSP同様、(ISC)² が認定を行っているセキュリティの国際資格です。SSCPはCISSPの方が有名で難易度高いためか、受験記・合格記が少なく、参考になるのは以下の記事になります。
OSCP(Offensive Security Certified Professional)
OSCPは、Offensive Securityのベンダー資格でペネトレーションテストに関する資格です。CEH(Certified Ethical Hacker)
CEHは、EC-Councilが提供するホワイトハッカーの認定資格です。【蓄えた知識の集大成】認定ホワイトハッカー試験(CEH:Certified Ethical Hacker)に合格できた勉強法
おわりに
セキュリティの資格はまだまだいっぱいあるので、合格された方々の記事を参考に自身の興味ある資格の取得に挑戦してみてはいかがでしょうか。【参考】
登録:
投稿 (Atom)