Google Apps Device Policyはじめました(冷やし中華風に)

企業ユースではイマイチセキュリティ面で弱い、とされているAndroid。（ここでいう「セキュリティ」とは端末紛失時のデータ漏洩への対策という意味ね。ウイルス対策とかの話はここでは無関係）
そんなAndroidのセキュリティ強化ソリューションの一つであるGoogle Apps Device Policy試してみました。
詳しくはこちら。
以上！

とかいうのはアレなので実際に使うまでに必要なことと出来ることをまとめてみます。

■必要な準備
☆管理者がすべき準備
・ドメインの管理権限を持っている必要がある。
・ドメイン内DNSにCNAMEレコードを追加できる、または、ドメイン内のWebサーバにコンテンツを追加することができる。
・Google Appsに自ドメインを登録して利用開始する必要がある。ドメイン登録の際、ドメイン管理権限を持っていることを証明するため、上記CNAMEレコードの追加またはWebサーバにコンテンツを追加することを求められる。
・Google AppsのEditionをBusinessまたはEducationにアップグレードする必要がある。Businessにアップグレードするためには、年間1アカウントあたり50ドルかかる。
・Editionアップグレード時にクレジットカードの入力を求められる。(1ヶ月間の評価期間中は請求されない。それまでキャンセル可能。)
・モバイルサービスの設定で端末の設定を行う必要がある。
　端末の設定はいわゆるセキュリティポリシーの設定です。詳しくは「できること」参照。
・Google Appsに各ユーザーのアカウントを登録する必要がある。

☆各ユーザーがすべき準備
・管理者が登録したアカウントでGoogleに一度ログインする。
・Android2.2以上を持っている必要がある。
・Android端末にGoogle Apps Device Policyというアプリをインストールする必要がある。Android Marketからダウンロード可能。
・Google Appsに登録したアカウントをGoogle Apps Device Policy設定時に選ぶ。

■なにが起こるか
・端末がGoogle Syncすることで、管理者が設定したセキュリティポリシーが端末に強制適用されます。

■できること
セキュリティポリシーの設定画面イメージは以下。



Androidだと緑色の小さいアイコンがある奴だけが利用出来る。
・端末へのパスワード設定をユーザーに要求
・パスワードの安全度を2段階(普通、強)から選択可能。
・パスワード最少文字数
・自動的に端末をロックするまでの時間
・誤ったパスワードを入力された際に端末をワイプするまでの回数
・ユーザを指定して任意のタイミングでリモートワイプ
・Android3.0だと端末内データの暗号化が利用可能
・ほかにもGoogle Apps Lookupとかが利用出来るみたい。
・My Deviceを利用すると紛失した端末の場所を地図上に表示したり、電話をかけたりすることができる。

■感想
・BlackBerry Enterprise Serverのセキュリティポリシー設定数が500項目近いことと比較すると機能的な充実度は圧倒的にBlackBerryの方が高いが、Androidだと最低限パスワードの強制適用とリモートワイプはできる。細かい設定したってどうせ使いこなせないんだったら、これで十分でしょ。みたいに思えなくもない。オレ、IT管理者じゃないから適当なこと言ってるけどｗ
・ドメイン登録あたりはちょっと面倒だけど、そこさえ通過すれば、何もサーバだのハードウェアだのを準備する必要がない。DNS立てられればそれでOK。思い立ったその日に環境を整えることができる。恐ろしいほど手軽に利用開始できる。ちょっとしたセキュリティ対策ソリューション用のサーバを構築するのと比べたら雲泥の差だ。
・自動的にGmailだのGoogleカレンダーだのがグループウェア的に利用出来るし、当然Androidとも何の違和感もなく連携する。うちの会社もこれ使えばいいのに。って本気で思う。きっとわけのわかんないウンコみたいな某リモートWebメールなんかより不正アクセスに対する強度は確実に高いし、死ぬほど見やすくて、メールの処理能力がハンパなく高い。
・パスワード強制されるのがウザイ。これだけでAndroid端末使うモチベーションが半減する。（まぁ、ある程度しょうがないんだろうけどｗ）

そんなかんじ。

コメント

コメントを投稿

このブログの人気の投稿

Execノードを使う

イメージ
ここのところずっと Node-RED のサンプルを見ながら各ノードの使い方を確認しています。 頭出しの記事はこちら をご確認ください。今回はExecノードです。Execノードを使うと外部のコマンドを実行することができます。コマンドが出力した、標準出力や標準エラー出力などをノードから出力できます。 標準出力の内容を出力する 最初に確認するサンプルは「 flows > node-red > function > exec > 01 - Get standard output from external command 」です。 Execノードのプロパティを見ると以下の通りになっています。 実行コマンドは「 echo 」 msg.payload で受け取った値を引数として利用 出力モードは「 コマンド終了時 - execモード 」 コマンド終了時に結果を出力します Execノードには出力ポートが3つあります。 標準出力 標準エラー出力 返却コード 実行すると、標準出力には「 Hello World! 」、返却コードには「 {code : 0} 」が出力されます。この挙動は特に説明することはないかと思います。 標準エラー出力の内容を出力する 次に確認するサンプルは「 flows > node-red > function > exec > 02 - Get error output from external command 」です。外部コマンドのエラーをポートに出力します。中身は先程のサンプルフローとほぼ同じですが、Execノードで存在しないコマンドを実行しています。 実行すると、以下のログが出力されます。これも説明不要かと思います。 実行中に出力する 最後に確認するサンプルは「 flows > node-red > function > exec > 03 - Run external command in spawn mode 」です。出力がコマンド実行中に行われるのがこれまでのサンプルと違う点です。 コマンドはwhieループ内で2秒おきに「 Hello 」を標準出力に出力し続けます。Spawnモードで実行するとループ内でechoコマンドが実行されるたびにログが出力されます。サービスっぽい...
続きを読む

SendGridのX-SMTPAPIヘッダの使い方（Section Tags、Substitution Tags編）

イメージ
前回に引き続き SendGrid についてです。 今回は SMTP API を使ってみました。 SMTP APIについて SendGridのSMTP APIは基本的には普通のSMTPプロトコルに則ったものですが、X-SMTPAPIヘッダというカスタムヘッダを使うことで機能を拡張することができます。 X-SMTPAPIヘッダについて X-SMTPAPIヘッダはSMTPプロトコルの拡張ヘッダです。 X-SMTPAPI: { "category": "newuser" } みたいな感じでJSON形式でパラメータを与えることで機能を拡張します。 Section TagsとSubstitution Tagsについて 今回はSMTP APIで使える機能のうちSection TagsとSubstitution Tagsを使ってみました。 Section TagsとSubsitution Tagsは送信メールの内容を宛先毎に特定の文字列を置換するための機能です。toと合わせて使うことで機能します。 例えば、X-SMTPAPIヘッダの値を以下のような形にします。 { "to": ["test1@xxx.xxx", "test2@yyy.yyy"], "sub": { "-body-": [ "-bodyFemale-", "-bodyMale-" ], "-favorite-": [ "バナナ", "カツオ" ], " "-nickname-": [ "ミキ", "サブロー" ] }, "section": { " "-bodyFemale-": "-nickname-さん！女性向けの商品のご紹介です。", "-bodyMale": "-nickn...
続きを読む

Joinノードを使う（その4）

イメージ
ここのところずっと Node-RED のサンプルを見ながら各ノードの使い方を確認しています。 頭出しの記事はこちら をご確認ください。今回はJoinノードの4回目です。終わらねぇ。 確認するサンプルは、 前回 に引き続き「 読み込み > サンプル > flows > node-red > sequence > join > 02 - Manual join mode 」です。 メッセージを結合してkey/valueオブジェクトにする 5段目のフローから見ていきます。ざっくりとした流れは以下のとおりです。 DataノードでCSVデータを送信する CsvノードでCSVデータをJSONオブジェクトに変換する msg.payloadには以下のような値が指定されたメッセージ4つに分解される { name: "Apple", price: 100 } Changeノードでmsg.payload内の値を以下のプロパティに設定する msg.topic = "Apple"（msg.payload.nameの値） msg.payload = 100（msg.payload.priceの値） Joinノードで、2個の受信メッセージごとにmsg.topicの値をキーとしてkey/valueオブジェクトに結合して送信する これを実行すると、以下のようにmsg.payloadにJSONオブジェクトが指定されていることを確認できます。 メッセージを結合して結合オブジェクトにする 先ほどは結合した値がkey/valueオブジェクトでしたが、6段目のフローでは単純にオブジェクト結合します。ざっくりとした流れは以下のとおりです。 DataノードでJSON配列を送信する nameをキーに持つオブジェクトとpriceをキーに持つオブジェクトを交互に含んでいます（実際、こんなに都合の良いデータが生成されることはあるんだろうか） Splitノードで配列データを個別のメッセージに分割します Joinノードで、2個の受信メッセージごとにオブジェクトに結合して送信する これを実行すると、以下のようにmsg.payloadに2個ずつのオブジェクトがJSONオブジェクトに結合されたものが指定されていることを確認できます。ちなみに、Joinノード...
続きを読む