はてなブックマーク

シンジです。世の中クラウドクラウド言っていますが、「オンプレあってのクラウドでしょうが！！」というのが、シンジの信念です。cloudpackも「サーバーは全てクラウド化しました」とは言っている物の、ネットワーク機器などはそこに存在しています。今回は、cloudpackのサーバーラックの中身をちょっぴり公開したいと思います。 つむたんはハイパーネットワークエンジニアです写真の人はシンジチームのつむたんです。社内インフラはもちろんのこと、AWS Direct Connectや、VPN接続も担当しています。扱えないネットワーク機器は無い！どころか、自宅にデータセンターを構える（BGP回してる）レベルのハイパーエンジニアです。基本的にシンジが理想を伝えて、つむたんが実装してくれます。最高。 電源の系統分だけUPS、停電も発電機で対応現・虎ノ門ヒルズオフィスには、サーバーラック用の電源として、100

シンジです。続報です。（前回の記事） 新たに正式なアナウンスがありましたので、各種発表の一部から要約してお伝えします。 脆弱性について証明書系の攻撃にて、中間者攻撃を受ける可能性 緊急度高いとされています。 影響度影響度は低いと考えます。 AWSの各種サービスには、事実上影響無しHTTPS/FTPSなどSSL証明書を使用していない場合は影響なしAmazon Linuxはリポジトリを更新済みで適用可能AWSのサービスで対象があるものの、順次対応される為、ユーザー影響は無し対象範囲2015/6/11以降の比較的新しいOpenSSLにしか影響がないUbuntu 15.04 (Vivid Vervet)（訂正します、ご指摘ありがとうございます）, Amazon Linux等該当のバージョンは1.0.2c1.0.2b1.0.1n1.0.1o対処方法影響を受けるバージョンの1.0.2系は1.0.2dへ

シンジです。これからチャットツールの導入を検討している組織が、何を基準に、どのようにして導入すべきかをご紹介します。上の画像はcloudpackが検証したチャットツールの全てです。cloudpackでは結果としてSlackを導入しましたが、ここではSlackに限らず、あらゆるツールを見ていきましょう。シンジはセキュリティ担当なので、その視点が強くなりますが、予めご了承ください。 なんの為に導入するのかこれからチャットツールを導入しようとしている組織の多くが、 チャットツールが導入済みであるにも関わらず活用されていない既にSMS、Facebook、LINEなどが暗黙的に使われている（統制できていない）メールでのやりとりが非効率的だと思っている数千人規模の場合、統制が取れない（ユーザーの一覧がパニックになる）といったケースでしょう（シンジ調べ） 特に大企業や中堅企業で聞くのが、これらのツールの

シンジです。そんなこと言ったらなんにも使えないじゃ無いか！というのはその通りなのですが、cloudpack - CTO鈴木は「自社のADからSSO（シングルサインオン）できないサービスは原則採用しないもん！」というポリシーを持っています。これって実際のところどうでしょうか？今回はcloudpackがどうやってSaaSを採用するかという内部資料の一部を特別に公開して、SaaSの選び方について考えてみます。 cloudpackは原則、AWSなどへのログインにパスワードを使いませんこちらは、「最強のセキュリティでAWSマネジメントコンソールにアクセスする方法」でご紹介した通りなので詳細は割愛しますが、社内ではパスワードを使うシチュエーションは、「パソコン/Macにログインするときと、SSOするときのみ」です。どちらにしてもADのユーザーIDとパスワードしか使いません。まさしくSSOです。SAML

（最新の記事を掲載しました） シンジです。またもやOpenSSLに重度の脆弱性があるとのことです。7月9日にアップデートがリリースされるそうですが、対象範囲などをcloudpackのCSIRT（脆弱性対応チーム）の運用に則って見てみます。 発表された原文を見てみるThe OpenSSL project team would like to announce the forthcoming release of OpenSSL versions 1.0.2d and 1.0.1p. These releases will be made available on 9th July. They will fix a single security defect classified as “high” severity. This defect does not affect the 1.0.

シンジです。Slackは導入へのハードルが高いと思っていました。ところがどっこい、使ってみれば意外や意外、非エンジニアのイマドキ女子達もサクサク使いこなしているではありませんか。本人達に感想を聞いてみました。 なんでSlack使わなきゃいけないんですかぁ？導入時は説明周りをしたのですが、今でも記憶に新しい、Backofficeのとある女子から発せられた一言です。 Facebookじゃダメなんですかぁ？LINEじゃダメなんですかぁ？言いたいことは痛いほどよく分かります。 そこで返したシンジの歴史的返答が、 会社は個人の情報とか資産とかを保護する義務があるのね。だからLINEとかから情報が漏れちゃったら怖いでしょ？？そんなこんなでいろいろ試してたらSlackに落ち着いたの。もう、何の説明にもなっていない。歴史的。 （実際はそれ以外にもSlackの採用理由はあるわけですが、この子達に何と言えばい

シンジです。みなさんは会社でどんなパソコンを使われていますか？中にはBYOD（私物持ち込み）の方もいるかもしれません。cloudpackでは社員に最高の労働環境を提供するべく、惜しみない投資をしています。そのご紹介です。 基本はMacBookPro 13inch、一部がWindowsノートバッテリーが付いていないと停電時に仕事できなくなってしまいますね。というわけでノート型が基本です。軽いミーティングで会議室〜なんて時も持ち運べて便利です。 リーダー以上はもう1台支給MacBookAirが支給されます。最高スペックです。 セクションリーダー以上はMacBookPro 15inch最上位Macは移行が楽なのでホイホイ入れ替えます。 基本はメモリ16GB以上もはや「メモリが足りなくて。。。」なんて言わせません。 WindowsノートのスペックがやばいIntel Core i7 最上位メモリ 3

シンジです。皆さんの会社には「セキュリティポリシー」などはありますか？企業規模や事業内容によって様々なものですが、cloudpack（アイレット株式会社）は、そのポリシーを明文化して、可能な範囲で公開しています。このホワイトペーパーを読むことで、cloudpackがAWSを利用する上でどのようなセキュリティ対策を施しているかが分かります。 なんの為に書くのかもはやホワイトペーパーは自分（自社）への戒めです。自分たちが作り上げたセキュリティポリシーを外部に公開することで、これには様々な反応があります。 これだけやってるcloudpackなら安心だ！この程度のセキュリティで何がcloudpackだ！というわけです。まずはセキュリティに対する取り組みの姿勢を見せることが大事です。このホワイトペーパーは、セキュリティの専門化の方もご覧になりますし、実際にご指摘を頂戴したりもしました。そうやって様々

シンジです。AWSへのログイン時、普通はアカウント名とパスワードを使いますよね？今時パスワードは危ないと思いませんか？そこで多要素認証ですよね。しかし、cloudpackは多要素認証すら使いません。何故なら、パスワードを入力するという行程がそもそも無いからです。 まず設備から揃えた まず社内インフラについては全てAWSに実装していますが、ここではDirect Connectを用いて専用線による接続を行っています。かつ、複数拠点を閉域網で閉ざされたネットワークを構成しています。 ではインターネットはどこから出入りするかというと、一度全ての通信は品川データセンターに集約されて、そこから単一のグローバルIPで通信するようになっています。 これによって、どの拠点からでもお客様環境にアクセスするIPアドレスは1つに完全固定出来るわけです。セキュリティグループの設計が楽になりました。将来的にはグローバ

シンジです。cloudpackのセキュリティ対策の一環として、USB充電器を大量買いした、そしてなぜこの製品を買ったのかという話の経緯です。 あくまでも抑止力業務性質上、スマホやタブレットを社内に持ち込ませないということが出来ません。むしろ、お客様がリリースされたゲームやアプリが正常にAWSと通信できているかを確認するためなどなどで、日常的に利用されています。 会社が支給するデバイスについては、別途MDMを行うなどの対策を行うものの、個人のデバイスについては「充電目的でパソコン・Macに接続される」ことが多々あります。 シンジチームではiPhoneなど全てのデバイス接続を検知している会社のネットワークに接続される全業務端末では、Thunderboltも含め、USBデバイスが接続されると、全ての通信が記録されます。同時に、デバイスへの通信制御も自動的に行う仕組みとなっています。ついでにアラー

cloudpackでは、セキュリティ認証として「プライバシーマーク」「ISMS」「PCIDSS」を取得していますが、内部統制を進めていく中で、チャットツールも例外ではありません。例えばFacebookを使ったとして、「書き込みを誤爆したらどうする？」だとか、「社員が退職したらコントロールできる？」だとか、「アカウントのリスト攻撃に耐えられる？」だとかの課題が出てきます。そこでツールそのものの使い方を考察するに至ったわけです。 比較したチャットツール群Yammer, Yammer Now, LyncFacebookHipchatSkypeChatWorkTalknoteサイボウズ KUNAILineこのうち、cloudpackの社内セキュリティ要件としてすぐに対応できるのはMicrosoft Yammerのみでした。cloudpackの内部で利用している統合認証によるシングルサインオンにOf

EC2にもGPUが搭載されているインスタンスがあるけど、科学技術計算用途に使えるのか試してみました。 結論から書くと、Marketplaceに用意されているNVIDIAのAMIは古くてなんとなく嫌なので、全部セットアップしてサンプル流してって軽く考えていたら大変だった。。。 結果的にはGPU1ノードで単精度1TFLOPSは出せたのでなかなか良いのではないのでしょうか？ まずEC2に用意されているGPUインスタンスは2種類しかありません。今回はg2.2xlargeを利用します。 Marketplaceからお手軽に試したい人は以下のリンクからどうぞ。 https://aws.amazon.com/marketplace/search/results/?page=1&searchTerms=GPU いい感じのAMIが無い美しいCUDA環境を作りたいが為にCentOS6.5を使いたいわけですが、先

[追記]しっかりした情報が中の人から発信されたので転載します！勉強になります！ CentOS6.5を VM ImportでEC2にインポートする http://understeer.hatenablog.com/entry/2014/04/09/172554 HPCをAWSでやろうと思ったときに困ったのが、自分好みの良さそうなHVM-AMIが見当たらない事でした。とあるJAWSDAYSにてAWS松尾さんから「VirtualBoXからイメージ変換してVM Importすれば簡単にHVM-AMI作れますよ（ｷﾘｯ」と伺ったときに、まじかー！と思ったのでやってみた。 前提条件ホストにしたクライアントはMac Book ProのOS X 10.9.2ゲストはCentOS-6.5-x86_64-bin-DVD1.isoVirtualBox 4.3.10 r93012ec2-api-tools-1.6