スマホユーザーのセキュリティ意識やばくね？
こんばんは、
セキュリティ企画第3回はスマホのセキュリティです。
第2回の標的型攻撃を調べていると、 ポピュラーな攻撃手段として社員のデバイスを狙うことがわかりました。
企業のセキュリティ対策と聞くとSQLインジェクションとか、 DDoSとかそういうメジャーな攻撃への対策ばかりが頭に浮かびましたが、 やはりセキュリティ対策しにくい「人」に近い部分を狙うんですね。
人から漏れるというキーワードで、 思いついたのが個人情報の塊のスマートフォンなんですが、 こいつからすぐに情報抜くことができるんですね。乗っ取りってやつです。
あまりに簡単に乗っ取りできるもんだから、ちょっと怖くなりました。
フリーWiFiを利用するとパケットが暗号化されていないから、盗聴・改ざんができてしまうんですよね。これが危ない。
ID/PWを入力する偽のログインページからID/PWを盗み見たり、 ページを改ざんしてどこをクリックしても、悪意あるソフトウェアをDLするなんてこともできるようです。
改ざん・盗聴をさせないために、そして不正なサイトにアクセスしてしまわぬよう、ウイルスが入ってきてしまったときに検知できるように VPNソフト+スマホ用のセキュリティソフトは必ず入れましょう！
批判動画を見て立ち止まる
こんばんは
日をまたいでしまいましたが、心の中では連続投稿記録は継続中。 はてなブログ上、また0に戻ってしまいましたが、、、
先日、確証バイアスの話をブログでさせていただきましたので、 批判動画を見ることで多少なりともフラットな気持ちにもっていこうという試みです。
DaiGoさんや堀江さんの考えが浅はかで賢いと見えたいばかを食い物にしているという、えらてんさんの発言がありました。 この点が解せないなと。ちょっとでも間違っていることを発信することがそんなに悪いことなのかと。 ある種の信念や経験に基づいて発信しているのだから、全面的に間違っているような発言は基本的にしていないだろう。
鵜呑みにして、実践して、自分なりの型にはめてみる。これが、成長するための必要なサイクルなんだと確信しています。 良質な情報を選別していく能力も必要ですが、実践から毒入りキノコなのかを判別していくほうが早いじゃないですか。 鵜呑みにして、実践できなければ/実践しないのであれば、それは鵜呑みにできていない。理解できていない。心が拒否しているということなんだと思います。
間違っていても、様々な情報をOUTPUTしていただける皆様には敬意を払いながら、これからも動画紹介をしていこうと考えなおした一日でした。
せきゅりてぃ❓
～第１回：なにから手を付けよう～
何から考えていけばいいのかがわからない。（10年もインフラエンジニアをやっていて新人かと自分にツッコミたくなる）
セキュリティ対策と一口に言うが、実態もイメージもつかめないので、 ミクロ(色んなIT分野のセキュリティ)を積み重ねることでマクロ(日本のセキュリティ)に近づこうと思う。
ECサイトを構築する場合のセキュリティを考えてみることにする。
今回はこちらのサイトから勉強させてもらった。
ポイントは、以下の5つ
- 攻撃／侵入が困難であること
- 侵入されても被害を局所化できること
- 監視／検知が機能すること
- 管理／運用が容易であること
- 調査／復旧が容易であること
そして、1個目でいきなり脱線の予感。
- 攻撃／侵入が困難であること 攻撃・侵入を困難にするといっても、考えることは基本的なことである、「必要なサービスだけを提供し、そのサービスを徹底的にセキュアにして、サービスを提供するサーバへのアクセスを制限する」に尽きる
難しく考えすぎていただけなのか、知らない侵入手段があるのかはわからないが、知らなすぎるがゆえに闇雲に不安がっていたような気がしてきた。 「LB経由でアクセスするサーバにはHTTPS/HTTPでしか侵入する方法はない」のだとすれば、すごくシンプルに考えられる気がする。
HTTPS/HTTPしか許可されていないとすれば、どんな攻撃手法があるのか と疑問がわいてきた。 保守のためにSSHが有効化されているケースは多いので、SSHとHTTP/HTTPSが侵入方法になるのかな。
HTTP/HTTPSでしか許可していないサーバに、魔法使いのように侵入する手段があるのか。 はたまた、結局はHTTP/HTTPSの脆弱性を突いただけのものなのか。
次回、魔法使いの化けの皮をはがす。
～おしまい～
亀の歩みで日本のセキュリティ対策を理解する
日本のセキュリティ対策が遅れているという記事を見て、あぁいつもの話ね。 と思ったが、よくよく考えてみるとセキュリティ対策ってなんだ。
日本のセキュリティの何が遅れているのか。 イスラエルが進んでいるといわれているが、どこにそんな差があるのか。
最終的に上記質問に回答できるように、セキュリティに関する連載記事を書いていこうと思います。
ペンタゴンクラウド契約!!
こんな情報が飛び込んで参りました。10年で100億ドルだと、毎年10億ドルか、、、
全体のベンダーの売り上げに比較すると、そんなに多いとは思えないですけど、 国防総省で実績ありですとか採用されてます、っていう信用度がとてつもない力ですね。
実績主義の日本では尚更…すぐ実績あるんですか だからね
Microsoftの強みは非常に強力な生産性アプリケーションを擁するAzure Stack。これはプライベートなミニAzureで、軍にとってはきわめて使い勝手がいいはずだ。 しかしMicrosoftだけでなくAmazonももちろん政府業務の経験は十分に積んでいる。両社はそれぞれにメリット、デメリットがあるので、どちらかを選ぶのは非常に困難な作業となる。
米国防省は1兆円超のJEDIクラウドの最終候補にMicrosoftとAmazonを選定、Oracleは選外 | TechCrunch Japan
・Azure Stackとは
Microsoft stands up Azure Stack for government as JEDI contract looms – TechCrunch
Microsoft announced today that it’s released Azure Stack for Azure Government at a time when it’s battling rivals at Amazon and other cloud companies for the massive winner-take-all $10 billion Pentagon cloud contract known as JEDI.
ふむふむ、Azure Stackのスキーマはペンタゴンクラウド契約に向けたものだったんですね。 使い方の例がいくつか紹介されているサイトがありましたので、添付しておきます。
以下同様にクラウド上にデータを置けない事情もわかりますので、オフライン(orオンプレ)利用というのは刺さりそうな気がします。
2つ目は、データをクラウドに置けないけどアプリケーション開発はクラウド型でやりたいというケース。 デンマークの投資銀行Saxo Bankは、政府の規制により金融データをクラウドに置けないため、 データはAzure Stackのオンプレミス環境で保持してアプリケーション開発はAzure側で行っています。
