Microsoft Tech Summit 2016に行ってきたメモ

行ってきました。

Microsoft Tech Summit|Microsoft

月並みな表現だけどエキサイティングでした。地に足の着いた技術と未来の技術がセットになってて面白かったです。

Day1

キーノート

11:30-12:20 Office 365 で実現する一歩先の情報漏えい対策(SEC002)

  • 最近のクラウド時代の流行り→CASB:Cloud Access Security Broker
  • クラウドに侵入されたら検知したいけど、ふつーの環境だと平均200日くらい経ってから気づくのでやられたい放題
  • そこでOffice 365 Advabced Security Management
    • 怪しいOffice365ユーザーを見つけて、管理者に通報する機能
    • ありえない移動とか、大量のファイルのダウンロードなどを検知
  • 管理者がやることはたった3つ
    1. 高度なセキュリティの管理を有効にする
    2. アラートメールが来たらポータルで確認する
    3. 脅威と認められたらユーザーを制御
  • Cloud App Security
    • シャドウITの検出。サードパーティー製も含む、SaaSアプリケーションの監査
    • FWのログをアップロードすればIP分析して、facebookとかGoogle使ってるかを検知もできる
    • Demo:Boxで外部ファイル共有を行ったユーザーのアクティビティを検出し、ファイルの共有設定を削除する
      • このデモは違和感。会社がユーザーがBoxを使っている事を把握した前提じゃん?
      • 結局会社がマジで知らないSaaSアプリは管理できないんじゃ?
        1. FWのログをアップロードして、社員が使っているSaaSアプリを一覧化
        2. そもそもアクセスしちゃダメなSaaSアプリはブロック
        3. その他のアプリは制御
      • という感じ?
      • SRに聞いてみよう(★Todo1)
    • O365の対象はExOL,SPS,Sharepoint Activity API?って書いてたけど
    • O365 ASMはこれのO365部分だけを抜き出したもの、みたいな
  • ライセンス
    • Advanced Security Management:E5付属。単品で300円/人
    • Cloud App Security:EM+S E5付属。単品で売ってる?
      • 組織にE3とE5のユーザーが混在してたりする場合はどうするんだろう?
      • SRに略(★Todo2)
  • アクティビティログ:180日保持 アラート:永久保存
  • アクティビティログはエクスポート可能
  • 使用できるOffice365ライセンスはE5

12:45-13:35 Azure ネットワーク設計と運用のツボ(DEP005)

  • 多分このセッションはスライド資料の方が理解が深まる
  • パブリックIPなくても中から外に繋がる。
  • サブネットに対してNSGをつけられる。(仮装マシン個々につけてもいいがサブネットにつける方が自然
  • NSGないとつるつる
    • 絶対にNSGを削除しないでね
  • ユーザー定義ルート
    • サブネットの内側に定義できるルーティング設定
    • 複数NICマジ無駄。オンプレと違って倍速とかならない
  • リージョン間の距離
  • VNETピアリング
    • 複数のVNETを簡単に接続できる
    • 旧VNETと新VNETも繋げちゃう
      • なので旧でVNET組んだから移行できない…とかはない
    • 1GB一円
  • AXN
    • 超早い。40~50Gbps
    • そのうち全部のIaaSマシンに乗りそう
  • azure内の通信はMS内で閉じるが、CDN宛のものはインターネット出る
  • azureのipは毎週水曜日にリリースされている
  • VPNゲートウェイでBGPサポートしたから自由度増えた
  • インフラエンジニアもJSONでテンプレ作って展開しよう
    • そんでバージョン管理してInfrastructure as Code (IaC)
  • canary vm
  • ネットワークのサポートは絶対入ってね〜!!!

14:00-14:45 アイデンティティのMVPが語るAzureADとアプリ連携の勘所(SEC020)

  • ID管理を導入するにあたって注意すべき事
    1. 識別子
      • UPNは何か?(社員番号?)
      • ADのドメインは?(.local?)
    2. アプリケーションの認証プロトコル
    3. ネットワーク
      • 固定IPでFixできるのか?
    4. バイ
      • 会社でインベントリ管理できてる?
      • 個別で買ってきたもの使ってない?
  • 現実的な対応

    1. 識別子
      • アプリ向けの識別子属性をAzureADの拡張属性に保持し、カスタム属性マッピングを行う
      • 他の属性についてもマッピング(下部表1)
      • 注意:SAMLトークン属性について
        • アプリケーションが指定するフォーマットでSAMLのNameIDを返す必要がある。
      • もし要求に応じたフォーマットで値が返せず、自動的にUPNの名前が返ってしまう(下部表2)
      • SAMLに対応している」だけではダメ。
        • アプリケーションがtransientの場合、persistentの場合、そもそも対応していないのでマッピングが返せない。
      • おすすめ:firefoxアドオン:SAML tracer
    2. アプリケーションの認証プロトコル
      • OIDC/SAMLじゃないっす対応
      • 対応すまで待とう、は無理なので…
        • パスワードSSO
          • ブラウザにアドオンを入力し、ID/Passwordを代理入力
            • Chormeで自動でID/Pass覚えるのとあんま変わらん
          • ログインURLが静的じゃないとだめなど製薬あり
        • Azure AD WAP
          • Kerberosじゃないとだめ、などの制約
          • AzureADWAP + PingAccess連携(ヘッダー認証)
        • WAM連携
      • などに逃げる
      • WAN連携とヘッダー認証がよくわかってなかったので勉強する(★Todo3)
    3. ネットワークの問題
      • 拠点ネットワークを絞り込み、無理な場合は例外ユーザーとか作る。
        • マイナー拠点対応、偉い人対応、みたいな
    4. バイ
      • 聞きそびれた
  • 表1

AAD側 アプリ側
UPN 123@foo.jp LoginID emp1234
displayname 山田太郎 displayname 山田太郎
ExtensionAttribute1 emp1234
  • 表2
属性 SAMLトークン属性
UPN nameid-fornat:unspecified
Mail nameid-fornat:unspecified
Onpremisessamaccountname nameid-fornat:WindowsDomainQualifiedName
ExtentionAttribute1-15 nameid-fornat:emailaddress
extractmailperfix() nameid-fornat:emailaddress

15:15-16:05 他と同じOffice365で満足ですか?Office365のAPIでオリジナルサービスに進化させる(APP009)

  • AzureADにアプリケーション登録
    1. 組織で開発中のアプリケーション
    2. クライアントID と クライアントキー取得
    3. アプリケーションのアクセス許可、デリゲートされたアクセス許可
    4. HTTP Request投げる → authコード取得
  • API叩けるよ
    • twitterやFBなど、最近メジャーなAPIの利用方法と同じ
  • 必要な権限だけ付与しないと、怪しいfb連携アプリみたいになっちゃうよ
  • 最近企業にウケるもの。Bot,AI,IoT。
  • Cognitive service,WebJob使って楽に面白く
  • APIでオリジナルサービスに進化させる
  • Exceed1の事例
    • 英単語勉強アプリ
    • Bossから来る英文メールの頻出単語をリストアップし、勉強できる
  • API利用のコツ
    • APIのスロットリングポリシーに気を付ける。エラーになったら時間を置く。
    • メールを操作する際にはGraphIDが頻繁に変更されるので、取りなおすのがよい。
      • ↑後からメモ見ると内容が分からんが、セッションを定期的に張りなおすとよい、と理解
  • Q1. outlook.とgraph.のAPIが混在している
    • A1. 今後graphに統一されるから特に理由なければgraph使ってね
    • 個人的にoutlookのv1がアプリ登録なしで叩けるので便利(twitterAPI 1.0みたいな)
  • Q2. SfBのドキュメントなくない?
    • A2 .ない。ってか分かりづらい。Skype Web SDKでやってね
    • 素のSkypeは企業向きじゃないんす
  • LUIS超楽
  • 関連:CogBot_CognitiveBotOverview_20161020 – Docs.com

16:30-17:20 AzureADでクラウドの認証基盤を統合したいけど、IDの安全性はどうする?(SEC008)

  • あんまりメモってない
  • 後でスライド期待

17:45-18:35 Cloud First、Mobile FirstにおけるID管理とは?-人(Identity)から始まるアクセス制御-(SEC004)

  • IDを分散させるとセキュリティが低下する
  • AzureADP使えばIP制限可能。アプリ毎にアクセス制御も可能
  • Intuneは進化中でiOSのIMEI登録して許可したデバイスからしかアクセスできないように出来る
  • すんませんあんまメモってない
  • ID系のセッションは後でまとめよう

Day2

9:00-9:30 PowerShellの新しい相棒 Visual Studio Code(APP017)

  • ‘code .’でvscode起動
  • 拡張紹介
    • vscode-pandoc
    • PlantUML
      • UMP図を書く
  • デバッグにはlanuch.jsonというのが必要だが、自動で作成されるので意識しなくてもよい
  • PSISE開発チームメンバーとVScodeの開発チームメンバーが同じ
    • 日次でアップデートしてるよ
    • 日本からのフィードバック待ってるよ
      • SJIS開けないのどうにかしてほしい

9:55-10:25 お客様とパートナー様のOffice365導入・定着化を支援するFirstTrack Center(PRD013)

  • EOPとかATPにも対応している。Notesからの移行についても対応している(IMAPとは別で)
  • その他は知ってる事でした

10:50-11:40 Office365におけるID統合とアクセス制御のベストプラクティス(PRD004)

  • オンプレ組織とO365ディレクトリ同期のデザインパターンについて
  • 知ってる事だったけど、空ですらすら話せない(考えないと話せない)のでもうちょい浸透させよう
  • 利用リージョンが分かれるとき、最も近いデータセンターに接続される
    • 例えばO365日本テナントを米国で利用する場合、米国のCDNを引いて米国のO365フロントエンドにアクセスしバックエンドのMSネットワーク経由でデータを取り出す
    • よってインターネット帯域の消費はしない
    • ただし、O365ポータルとExOLのみ。SfB,SPOは近くのサイトに接続。
      • Onedriveはどうなんだろう…?
      • SRに(★Todo4)
  • Office365への他テナントへのアクセス制御もうすぐ来るぽい

12:00-12:45 [ランチ付き] Azure IaaS 応用編~実務で使えるVMとPaaSの組み合わせ~(SNR001)

  • ごめーん知ってる事ばっかりだった

13:10-14:00 プロトコルマニアックス~ OAuth 2.0/OpenID Connect/FIDO 2.0/SAML 2.0 違いと用途(SEC010)

  • SAML 2.0
    • RP Initiated
    • IdP Initiated
    • RP Initiatedがよく使われる。最初にAppにログイン試行する方法。
  • OAhth 2.0
    • facebook認証とかtwitter認証みたいなん
    • 表面上の話だと、アプリがIdPから取り出したい情報を定義できるのが大きい
    • OAuthの場合、必須情報以外はユーザーがアプリに渡さないことが出来る
    • アクセストークン:トークンを使ってユーザー情報を取り出す
    • リフレッシュトークン:トークンの有効期限が切れた時に、新しいトークンを発行する役割
  • SAMLとOAuthの違い
    • 情報を出すのがIdPか本人か
    • OAuthは認可をするプロトコルなので、アプリケーションは不安
  • OIDC
    • 2014年に登場
    • OAuthにユーザーの認証機能を組み込んだもの
    • OAuth2.0 + ID Token
  • 企業の話
    • 企業だからといって勝手にSAML2.0で個人情報出していいのか?OIDCで個人に確認を取って出すべきではないのか。
  • FIDO 2.0
    • 生体認証とかでサービスを使いたい
    • 「パスワード以外の選択肢」スライドが素晴らしい。
      • “パスワードはすぐ盗まれる”と言葉で言っても、こういうスライド1枚の破壊力
  • パスワードとPINの違い
    • ID(例:スマートカード)とPINの組み合わせ。物理デバイスに紐づくPINは1つであり、対応がマッチすればPC内で認証が完結する。
    • Trusted Platform Moduleに秘密鍵を保存する
    • ユーザーIDとPINを渡すと、TPMに保存されている秘密鍵にアクセスできる
    • 秘密鍵を利用して、サインイン要求に署名する。サーバー側で対応する公開鍵で複合する
  • まとめ
    • SAML 2.0よりOIDC 2.0
      • SAMLでユーザー認証すんじゃねぇ
    • ユーザー認証部分はFIDOが本命
    • FIDOでユーザー認証して、OIDCで認可(権限付与)する

14:25-15:15 クラウドで守る! Exchange Online の最新セキュリティ対策(PRD005)

  • EOP/ATPの話
    • だいたい知ってた
  • EOP新機能:Anti-spoofing protection
  • EOP新機能:Zero-hour Auto Purge: ZAP
    • EOPがスパムと認定した後でも、過去にユーザーが受信したメールをさかのぼって迷惑メールフォルダに移動する or 削除する
    • ただし未読のメールのみ
  • ATP
    • URL Trace機能
      • 現時点ではリストベースの判断。
        • マジかよ知らんかった
      • 今後は、実際に開いてページの中身を確認する(Sandbox)。動的であるので安全だが、ちょっと遅いかも?Linked Content Detonationというらしい
    • Dynamic Delivery
      • 今までだとATP通るのに5分~10分かかってしまう。これからは本文だけは送って添付ファイルは後から送る機能
        • これ欲しかった
  • ATPの拡張
    • ExOL以外にも広がってくよ~
      • 値段変わらないのかな?
  • DKIM署名対応
  • Q1. ATPって送信元によってATPする、しないを選べないの?
    • A1. 送信者が組織内のメールだとATPされない。それ以外だと問答無用でされる。

15:40-16:30 詳説 – Rights Management Services / Azure Information Protection(SEC016)

  • RMSの話
    • セルフサービスサインアップ
    • AAD使ってない個人が人から送られたRMSを読むために勝手にAAD登録すると、そのドメインがカスタムドメインとして登録されてしまう。
    • また、オンブレRMSがある環境だと、そのユーザーはオンプレとオンラインを同時に使えるようになってしまう。
      • が、メーカー非推奨なので、オンプレRMSが使えなくなったりするかもしれない。
    • これ、やばくねーか
  • それ以外は知ってる事でした

15:40-16:30 Xamarin と Azure で、超効率的にクラウドと繋がるモバイルアプリを作ろう!(APP005)

  • RMS途中退室してこっち
  • 人めっちゃいた
  • 楽しそうにデモしてるのが印象的でした
  • XamarinとAzure Mobile Appsでモバイルアプリ開発!

16:55-17:45 OMS Log Analytics によるビッグデータログの分析方法の解説と実演(DEP002)

  • 最近インフラやってないけどSCCMとOMSでこういう事出来たなら速攻導入したかった
  • Sandbox環境もあるので是非
    • URL忘れた

18:10-19:00 条件付きアクセスを徹底理解 – Azure Active Directory で実現する場所とデバイスの“条件付きアクセス制御”-(SEC007)

  • 他のID系のセッション出たので知ってる事ばかりだった

18:10-19:00 エバンジェリストが注目のこの人と語る IT キャリアの多様性と未来(SPL005)

  • コント…?
  • 面白かったです

参加したセッションまとめ

  • ID系
    • アクセス制御
      • Day1:16:30-17:20 AzureADでクラウドの認証基盤を統合したいけど、IDの安全性はどうする?(SEC008)
      • Day1:17:45-18:35 Cloud First、Mobile FirstにおけるID管理とは?-人(Identity)から始まるアクセス制御-(SEC004)
      • Day2:10:50-11:40 Office365におけるID統合とアクセス制御のベストプラクティス(PRD004)
      • Day2:18:10-19:00 条件付きアクセスを徹底理解 – Azure Active Directory で実現する場所とデバイスの“条件付きアクセス制御”-(SEC007)
    • デリバリ
    • 仕様
  • O365系
    • App
      • Day1:11:30-12:20 Office 365 で実現する一歩先の情報漏えい対策(SEC002)
      • Day2:14:25-15:15 クラウドで守る! Exchange Online の最新セキュリティ対策(PRD005)
      • Day2:15:40-16:30 詳説 – Rights Management Services / Azure Information Protection(SEC016)
    • Dev
      • Day1:15:15-16:05 他と同じOffice365で満足ですか?Office365のAPIでオリジナルサービスに進化させる(APP009)
      • Day2:9:00-9:30 PowerShellの新しい相棒 Visual Studio Code(APP017)
    • Ope
      • Day2:9:55-10:25 お客様とパートナー様のOffice365導入・定着化を支援するFirstTrack Center(PRD013)
  • Azure系
    • Day1:12:45-13:35 Azure ネットワーク設計と運用のツボ(DEP005)
    • Day2:12:00-12:45 [ランチ付き] Azure IaaS 応用編~実務で使えるVMとPaaSの組み合わせ~(SNR001)
  • その他
    • Day2:15:40-16:30 Xamarin と Azure で、超効率的にクラウドと繋がるモバイルアプリを作ろう!(APP005)
    • Day2:16:55-17:45 OMS Log Analytics によるビッグデータログの分析方法の解説と実演(DEP002)
    • Day2:18:10-19:00 エバンジェリストが注目のこの人と語る IT キャリアの多様性と未来(SPL005)

まとめ

  • はらへった
    • 近くにコンビニほしかった
  • 2日で6万円の元取るためにレッドブルとモンスター飲みまくった
    • 5本飲んだので1000円分
  • OneNoteっていうかSurfaceのペンをもっと使おうと思った
  • ID系出過ぎた
    • 全然関係ないセッションにもっと出ればよかった
  • 内容濃かったから腹落ちさせて整理展開しないとな~

関連

Visual Studio CodeでPlane Text(.txt)で自分独自記法のハイライト表示

Sublime Text – Plain Text(.txt)で自分独自記法のハイライト表示 – Qiita

と同じく、僕もメモ帳ベースで自分独自記法のTodoリストを使ってます。

サクラエディタだとこんな感じ。

f:id:teraco:20161015121318p:plain

VSCodeでの独自シンタックスハイライト方法を調べてみました。

マニュアルなど

Visual Studio Code Colorizers

に載っています。簡単にまとめると

  1. tmLanguageファイルの用意
  2. VSCode用にコンバート
  3. VSCodeにインポート

となります。では1.から行きます。

1. tmLanguageファイルの用意

多分これが一番めんどくさいのですが、自分独自記法のtmLanguageファイルを用意します。サクラエディタだと簡単に書けるのに…。

syntax highlighting – How to create a simple custom language colorization to VS Code – Stack Overflow

tmLanguageの作り方の詳細は別でまとめるとして、今回は

Revision – Stack Overflow

に投稿されているソースを元にコンバートします。

※ メモ:tmLanguageファイルの書式

TextMate Manual » Language Grammars

2. VSCode用にコンバート

用意したtmLanguageファイルを使用してコンバートをします。手法は最初のVisual Studio Code Colorizersに載っています。作業の前に”Yeoman and the VS Code Extension generator”というものをインストールしなければいけないです。

The Yo Code Visual Studio Code Extension Generator

さらに、”Yeoman and the VS Code Extension generator”をインストールするために、npmというNode.jsのパッケージ管理システムをインストールしなければいけないようです。

How to Install Node.js® and NPM on Windows – Treehouse Blog

これらの準備が整った後、

yo code

でコンバートを開始します。参考までに画面ショットを載せておきます。

f:id:teraco:20161015121326p:plain

ここでの設定なのですが、tmLanguageファイル中のfileTypesに準拠しないと、コンバートは成功するもののVSCode起動時に正常にパッケージを読み込んでくれずシンタックスハイライトが効かない状態となります。

        <key>fileTypes</key>
<array>
<string>log</string>
</array>

おそらく、生成されるpackage.jsonとsyntaxes配下のファイル紐づけの問題かと思いますが、詳しいことは分かりませんでした。

3. VSCodeにインポート

実行したフォルダ直下に以下のような言語パッケージが生成されるので、

f:id:teraco:20161015121328p:plain

それを

%USERPROFILE%\.vscode\extensions

に配置してVSCodeを再起動します。

結果

f:id:teraco:20161015121539p:plain

ひとまず、シンタックスハイライトが効いていることを確認できました。この状態になれば

%USERPROFILE%\.vscode\extensions

配下のtmLanguageファイルを直接いじって色を変える・ワードを追加するのもOKかと思います。おかしくなったら言語パックをアンインストールして本手順を1から実施します。

サクラエディタ使いがVisual Studio Codeを使い始めた

理由はいろいろありますが使い始めました。

ダンなエディタを触りたい

2000年代前半のテキストエディア全盛時代よりサクラエディタでメモ書き~スクリプト開発してきました。2000年代後半にIDEが流行り始めた時も、開発者ではない・インストールに手間がかかる・重いなどの理由でテキストエディタを使い続けてきました。

そして2016年。Windowsに標準でIDE(Powershell ISE)が装備され、次世代テキストエディタ(sublime text,Atom)が登場し、軽くて無料のIDEが流行り始めた今、さすがにテキストエディタ一択ではいかんでしょということで時代についていく道を選択しました。

選んだもの

Visual Studioが無料ではありましたが、そこまでがっつり開発しない & 全機能を使い倒せる自信がなかったため、テキストエディタベースのものを選択。MSに親和性のある仕事をしているってことで、Visual Studio Codeを使うことにしました。

VSCodeのいい所

軽い

文字を打つのにストレスではない。これが一番大きい。少なくとも触った感触はサクラエディタと同等以上ではないといけなかったので、これは必須条件でした。

マルチプラットフォーム

Windows,Linux,MacOSで同じ操作性。サクラエディタを使ってて一番困ったのは、他のOSで全然動作しない、ということでした。MacOSを使っている時期に、Windowsエミュレーター上でがんばって動かしてたことはあったけど…。無理やり。

ダン

インテリセンス対応、シンタックスハイライト対応、gitへのアップロード対応など。つまりVisual Studio Codeについていけば、自然と最新を追っていける…?

将来性

MSが見てるので、いきなりぽしゃったり明後日の方向に行くことはないかな、と。dropboxEvernoteなどの事例もあり、当初良くても数年後に斜陽になっている製品に乗るのが怖い今日この頃です。

今のところ実施した設定など

公式の方は基本的な文字列操作から書いてあるので覚えるまではここを参照。

powerpointのテンプレート名称が削除できない

マジどうでもいいバグなのですが。

powerpointファイルのプロパティに”テンプレート”という属性があります。ここにお客様名などを使用している資料を別のお客様に展開する場合、情報漏えい防止の観点でお客様名を消したいです。しかし結論としては消すことが出来ません。

削除方法

エクスプローラーからファイルを右クリックしてプロパティの削除から削除できるはずなのですが。

ファイルのプロパティ情報を削除する | 初心者のためのOffice講座

Windows10ではバグで削除できないそうです。

detail.chiebukuro.yahoo.co.jp
www.makotoiwasaki.com

※ COM Surrogateの実体はdllhost.exeのようですが、殺してもすぐ復活します。

なお、mp3や動画ファイルなど非MS製のフリーソフトが存在するファイルは、そいつを使って無理やり属性を削除できるみたいです。ただpowerpointフリーソフトなんて聞いたこと無い(LiberOfficeならいけるのか?)

悔しいので

Windows7(PowerPointインストール済み)でやったら削除できました。しかしながら、スライドマスター名だけは残ってしまいました。

結論

powerpointファイルを新規作成し、そこに内容を貼り付けたほうが早い気がしました。

MCP70-533を取得したのでメモ

こちらです。

Exam 70-533: Implementing Microsoft Azure Infrastructure Solutions

受かりましたので合格方法をメモします。

公式の動画とテキスト、問題を解く。

(MCP 70-533 対応) Microsoft Azure インフラストラクチャ ソリューションの実装
http://www.microsoftvirtualacademy.com/training-courses/mcp-70-533-microsoft-azure

(MCP 70-533 対応) Microsoft Azure インフラの実装 ~ Part 1 仮想マシン
http://www.microsoftvirtualacademy.com/training-courses/mcp-70-533-microsoft-azure01

(MCP 70-533 対応) Microsoft Azure インフラの実装 ~ Part 2 Azure Active Directory の実装編
http://www.microsoftvirtualacademy.com/training-courses/mcp-70-533-microsoft-azure-part-2-azure-active-directory

上記動画の理解と、NextStepと称されるpdfの問題集に取り組みました。まーこれだけでいいんじゃないかな?

ぁゃιぃ問題集をやる

某所で入手した、問題の日本語訳と回答が怪しい問題集もやりました。

結論

結果的にはぁゃιぃ問題集あって楽できました。公式の動画と問題集で内容は網羅されているのでこれらを勉強し尽くせばよいのですが、問題集で4択の問題が本番では1つずつ順番を指定する方式に変わっていたりして、問題集の4択を覚えてしまっていると迷ってしまったりしたので。

公式動画は今から1年以上前のものであり、アフィニティグループやWebApp、ストレージのプランなど、今となっては古い内容も含まれた内容ですが、本番の試験ではそういった内容は出なかったように思えます。

僕は教科書読むより問題集で間違いだったものの理解を深めるやり方のほうが好きなので、動画を1回見た後は問題集を繰り返しやりました。正解を覚えるんじゃなく、なぜ正解の選択肢になるのか、なぜ間違いの選択肢は選べないのか、を1問ずつ自分の言葉で説明できるように取り組みました。結果、ぁゃιぃ問題集は「これ間違いやろ~」というのがいくつもあって、それは参考までに答えを覚えて本番で出たらその時考えよう作戦。

勉強時間は15時間ほどですが、仕事である程度下地があってのものなので、人によってはもうちょいかかるかも。ストレージからネットワーク、IaaS、SaaSまで幅広い知識が求めらたので、専門外の分野を全然知らない、だと辛そうです。個人的にはオンプレで一通りやった上に自分でWeb系の勉強していたので、問題集の内容に腹落ちする事が多く面白かったです。

Microsoftアカウントと組織アカウントの違いについて

MSのアカウント管理はややこしいなーと思うのでメモです。

AzureやらOffice365やらを使う時に「あなたのアカウントはMicrosoftアカウントですか?それとも組織アカウントですか?」と聞かれる。

Microsoftアカウントとは?

一般市民がGmailYahoo!メールで登録できる、普通のアカウント。私的なアカウントというか。Googleで言うと、そのまんま”アカウント”となる。

組織アカウントとは?

Microsoftクラウドサービスを利用している会社が発行するメールアドレスで、登録したアカウント。

例えば、株式会社TESTがOffice365を使用するとして、xxx@test.comというドメインでOffice365を利用したとする。この時、当然Microsoftは@test.comのドメインで登録されたメールアドレスはMicrosoftのサービスを利用しているということを知っている。なので、@test.comを持つメールアドレスは、組織アカウントとして登録する権利を持つ。

一方、@gmail.comや@yahoo.comというドメインのメールアドレスは、Microsoftの辞書にない。あるいは、Unixベースのメールシステムを使用している@oracle.comというドメインも(有名ではあるが)Microsoftの辞書にないため、組織アカウントとして登録することが出来ない(※1)

Microsoftが”組織アカウント”と”Microsoftアカウント”に分けている理由、もうちょい言えば”組織アカウント”なる定義を作っている理由だが、例えばMicrosoftのゴールドバートナーの会社に特典を付与する場合、その会社の組織アカウントでMSのサイトにアクセスする必要がある、などMicrosoftの管理上の問題といえる。つまりMSの都合。

使う側にとっては、必ずしも組織アカウントで登録する方がいい、とはいえず、Microsoftアカウントでしか出来ないようなアクションもある。とはいえ、MSのゴールドパートナークラスの会社なら、同じAzureを使うにしても組織アカウントで使っといたほうが何かといい(この会社の従業員はMSにお布施してくれてるな、というのが分かる)ような気がする。

ちなみに

  1. とある会社はMicrosoftのサービスを使っていない
  2. 従業員がその会社のメールアドレスをMicrosoftアカウントとして使用
  3. とある会社がMicrosoftのサービスを使用開始し、メールアドレスが組織アカウントして登録可能になる

このケースの場合、2で会社のメールアドレスをMicrosoftアカウントとして登録してしまった人はどうなるかというと、そのアカウントは一生Microsoftアカウントとなり、組織アカウントには登録できなくなる。それが私なのだが、救済策として、表示上はMicrosoftアカウントだが、特典などは組織アカウントと同等に受けられるようになる。

ややこしいのは、ドメイン自体は組織アカウントなので、「あなたのアカウントはMicrosoftアカウントですか?それとも組織アカウントですか?」と聞かれて組織アカウントを選択した場合、そもそもアカウント自体が存在しない扱いのため一生ログインできないというハメに合う。そのハメに合ったため、この記事を書いている。

自分用メモ

  1. イニシャル@xxx.com 組織アカウント。O365にログインして各種サービスを使えるのはこれ。
  2. イニシャル@xxx.co.jp Microsoftアカウントだが実質組織アカウントでいろんな権限が付与されている。パスワードは大文字7桁+1(どうやら同盟の組織アカウントも存在していることになるらしい?)
  3. 名.姓@xxx.com 1のエイリアスであるが、Azure利用上は1と違うアカウントになるぽくてよく分からない。Microsoftアカウントぽい。
  4. xxx@gmail.com クリーンなMicrosoftアカウント

※1 正確に言うと、AzureADにドメインを登録していれば、Microsoftに課金していなくても組織アカウントとして認められそうだが、ここらへんは試していないのでよくわかりません。

Office365のIMAP移行を試す話

Postfix + Devecot環境のメールシステムからOffice365への移行をすることになった。Office365のIMAP移行というのはよー分からん、ということで、試しにGmailのテストアカウントからOffice365への移行を行うことにした。

prius.hateblo.jp

環境

Office365の新規テナント契約

  • exoadmin@tokyoppp01.onmicrosoft.com
  • よく使われる8文字

テスト用Gmailアカウントの取得

  • tokyoppp01@gmail.com
  • よく使われる8文字 + 自分用7文字の5~大文字

IMAP移行バッチの作成

以下のマニュアルを参考に、移行バッチの作成を行う。

注意点は以下。

  • 2016/7/19時点では、新管理ポータルはプレビュー版なので、GUIからやる時は旧ポータルを使用する
  • おそらく、一度移行エンドポイントを作成後(今回の場合、GmailへのIMAP接続)は、2回目移行の利用でそれを利用できるので手順が異なる
  • 移行バッチには最大同期数の制限(100?)があるらしいので、抵触しないようにする
  • とはいえ、100以上のユーザーを同時に同期状態にするとネットワーク負荷が高くなりそうなので、順次移行を検討するのがよい。
  • 例:ユーザー数1,000人の場合、50人単位で移行バッチを実行し、同期が終了したら元メールシステムに転送設定を入れ、IMAP移行バッチ自体は解除する、など。
  • その他、移行できるアイテム数と1アイテムあたりの容量に制限があるので注意

結果

ほとんど空っぽなテストユーザーのデータが3分ほどで同期状態となった。この後は、24時間に1回くらいの頻度で差分同期が走るらしい。
つまり、これは大事なことなのだが常に元のメールシステムのデータが正であるということ。

実際の現場では

  1. 同期バッチ完了
  2. 元メールシステム→新メールシステムへの転送開始
  3. 24時間後の同期完了
  4. 同期状態解除

の順番でないとと、漏れるメールが発生する。3が終わってから4するのが大事。

こう考えると、移行バッチはユーザー1名1名単位で実装るのがよいか。1バッチ中の人数が多ければ細かい転送設定制御ができず、ネットワークトラフィックに無理が出てしまう…。

コマンドライン

以下の様なものが用意されているらしい。

  • Complete-MigrationBatch
  • Get-MigrationBatch
  • Get-MigrationConfig
  • Get-MigrationEndpoint
  • Get-MigrationStatistics
  • Get-MigrationUser
  • Get-MigrationUserStatistics
  • New-MigrationBatch
  • New-MigrationEndpoint
  • Remove-MigrationBatch
  • Remove-MigrationEndpoint
  • Remove-MigrationUser
  • Set-MigrationBatch
  • Set-MigrationEndpoint
  • Start-MigrationBatch
  • Stop-MigrationBatch
  • Test-MigrationServerAvailability

New,Remove,Set,Start,Stopは手動でやるとして、Get系はエビデンスを取得するために使えそう。あとはTestか。

追加検証

GB単位のGmailアカウントはどれくらいで移行できるんだろう?と興味があったので今やってます。

適当にAzureサービス使ったら4万円課金された話。

この前の記事には背景がありまして。

prius.hateblo.jp

背景

半年前くらい、少し時間が出来たのでAzureサービスをいろいろ触ってみてました。その中の一つの「メディアサービス」というのがあり、何やら自分が作った動画をUPしてAzureCDN経由でインターネットユーザーに提供できるとのこと。こいつぁ夢の技術だわ!ってことでメディア関係のアカウントを作成しキャストをONにし動画をUP。Internetに公開し「Azureってエンタメ関係も強いんだ!すげー!」となったのですが…。これやるならyoutubeでよくね?という事に気づき、動画の公開を停止したのでした。

その1か月後。ふとAzureの請求を見てみると4万円とのこと。どうも、メディア関係のアカウントをいろいろいじっていた時に「ストリーミング」をONにしたまた放置していた様子。ストリーミングという名前から想像できるよう、時間当たりの課金額はすさまじく、1か月たらずで4万円の課金になったのでした。1か月の間、真っ暗な画面をストリーミングしていただけで…。

ネット上ではアカウントハック起因の救済措置のレポートも上がっていましたが、僕はれっきと自分でAzureサービスを使っての課金なので、授業料として4万円払いましたとさ。

まとめ

結局悪いのは、当時のAzureで課金アラートが設定できなかったことでした。通常Azureの使用量が月に5000円程度なので、例えば1週間で5000円使っていれば明らかに怪しい。その後課金アラートが設定され、とりあえずの対応はできるようになったのですが。

クラウド運用で課金管理ってのは最も重要な運用要素の1つだと思います。
というのは、理論上、リソースが無限に作れちゃうので、課金管理が唯一無二のリソース管理ポイントなんですよね。
もちろん、何らかの仕組みで「各部署につき、A2クラスの仮想マシンを10個まで作ってよい!それ以上は制限する!」と入口で管理することもできますが(多分)、クラウド時代においてはナンセンスであり「各部署につき、1月10000円まで自由に使ってよい」と、スマートに出口=課金で管理したい。

そのためには、前述のbillingAPI使ったり、もうちょい便利なサードパーティ製品(CloudCruiserなど)を使ってもいいと思います。特に会社でやる時はね!

Azure Powershell でAzureの課金情報をゲット(Billing API)

ついうっかり使いすぎて月末に泣かないように、日次で課金情報を取ろうと考えました。
自動で取得するとなるといちいちログインの必要のない、Azure REST API経由で取得します。

準備としてAzure Powershellをインストール。2015/11/23現在のバージョンは1.0.1となります。

memobog.azurewebsites.net

どうも1.0.0以上とそれ未満ではコマンドの仕様が違うらしく。
そもそもAzureのGUI管理インターフェイスはAzure管理ポータルとAzure Portal(Perview)の平行運用が続いており、Powershellもそれに合わせてSwitch-AzureModeでどちらのGUIに合わせた操作をするか選択する仕様だった。が、いちいちモードチェンジが必要なのが不評だったらしく、1.0.0からはSwitch-AzureModeは廃止、Azure Portalを操作するコマンドがAzure-RMなんちゃら~と着くようになったらしい。

statemachine.hatenablog.com

課金情報をゲット

結論から言うと、以下のページのコードが非常に使いやすく、コピペコピペでいけてしまう。

yomon.hatenablog.com

自分用に忘れそうな所だけをメモ。

キモとなるのは、認証用ヘッダーの作成と、アクセス先URLの作成。

$requestHeader = @{"Authorization" = $authHeader}
$usageUri = "https://management.azure.com/subscriptions/$subscriptionId/providers/Microsoft.Commerce/UsageAggregates?api-version=$apiVersion&reportedStartTime=$reportedStartTime&reportedEndTime=$reportedEndTime&aggregationGranularity=$granularity&showDetails=$showDetails"

認証用ヘッダー

# REST API実行用パラメータ設定
$clientId = "1950a258-227b-4e31-a9cf-717495945fc2" # Well-known client ID for Azure PowerShell
$redirectUri = "urn:ietf:wg:oauth:2.0:oob" # Redirect URI for Azure PowerShell
$resourceAppIdURI = "https://management.core.windows.net/" # Resource URI for REST API
$authority = "https://login.windows.net/$adTenant" # Azure AD Tenant Authority
(中略)
# Create Authentication Context tied to Azure AD Tenant
$authContext = New-Object -TypeName "Microsoft.IdentityModel.Clients.ActiveDirectory.AuthenticationContext"  -ArgumentList $authority
# Acquire Azure AD token
$authResult = $authContext.AcquireToken($resourceAppIdURI, $clientId, $redirectUri, "Auto")
# Create Authorization Header
$authHeader = $authResult.CreateAuthorizationHeader()
  • $clientId
  • $redirectUri
  • $resourceAppIdURI

は固定値です。

RESTと言えばGUIから管理画面にログインして秘密鍵っぽい文字列を取得しスクリプトに埋め込む…というやつであるが、Azure REST APIの場合、テナントIDが秘密鍵的存在になるっぽい。なので「俺のテナントID、○○なんだよね~」って言いふらしてはダメです。

テナントIDは以下のコードで取得可能。

$adTenant = (Get-AzureSubscription -SubscriptionId $subscriptionId).TenantId

なのでテナントIDさえ取得しちゃえばコードは固定できる。アクセストークンの期限は1時間(だった?)なので、トークンだけは毎回取り直した方がよいです。

※ これ、サブスクリプションの管理者が複数いる場合、テナントIDは全員で共通なのかな…。一人がヘマしたら全員のリスクなんだが…。さすがに考えられてるとは思うが(僕のやり方がリスクあるだけかも)

アクセス先URL

$usageUri = "https://management.azure.com/subscriptions/$subscriptionId/providers/Microsoft.Commerce/UsageAggregates?api-version=$apiVersion&reportedStartTime=$reportedStartTime&reportedEndTime=$reportedEndTime&aggregationGranularity=$granularity&showDetails=$showDetails"

ここには

  • $subscriptionId
  • $apiVersion

を指定すればよい。
$subscriptionIdはadd-azureaccount後、Get-AzureSubscriptionすれば出てくるし、$apiVersionは”2015-06-01-preview”で固定なので問題なし。

まとめ

上記理解の元、コードをコピペコピペで発行すれば大丈夫。種別の絞り込みとかはpowershellの元々の知識を生かしてがんばる。

気になった点として、個人アカウントで仮想マシンが1つもないサブスクリプションだと「課金レポートを作ってるから5分ほど待ってくれ」って202が返ってきたことかな…。これは仮想マシンがないからそうなるのか、単純に個人のアカウントだから動作が違うのか、そこまでは調べてません。

システム構築時のホスト名の命名方法について

一時期検討したのでメモ。

議題

自由にネーミングルールを決定できる場合、以下の用に名前付けすると効率がよいと思われる。

[システム名][サイト名][サブシステム名][役割][連番]

例:TEMSDB001

TE システム名(TESTシステム)
M/Sサイト名(Mail/Sub)
S ミドルウェア名(SQL)
DB 役割(DBサーバー)
001 連番

検討ポイント

  • 名前を正規化し、スクリプト等で扱いやすくする
  • アルファベット順で並び替えた際、構築対象サーバーがひとまとまりになるようにする
  • 人間がそれなりに呼びやすい名前とする

以下、その他検討したケースとダメな理由をメモ。

まず、どのような要素を”名前”に含めるかどうか。趣味のサーバーでなければ、分かりやすく管理しやすい名前がよい。

(星座の名前とか競走馬の名前は研究室のサーバーで十分)

必須要素

  • サーバーの役割
    • さすがに必須である
  • 連番
    • 同一役割のサーバーを複数台構築するのがほとんどなので必須。
  • システム名
    • エンタープライズシステムの場合、他部署が管理しているシステムと区別するために必要
  • ロケーション名
    • 一昔前なら不要だが、サーバーのサイトを分けて構築するケースが増えてきたので必要と思われる。
  • ミドルウェア
    -サーバー台数が多い場合、システム名+役割+連番では上手く命名できない事が多いので、含めておくと後で助かる場合がある

不要要素

  • OSバージョン
    • 一度構築したサーバーのOSをアップデートして使用するケースは少ないが、サーバーに付与しても何の情報にもならない
  • 製品名
    • 吸収合併の多いIT業界で製品名を付けると、何年後にはサーバー名と製品名称が不一致になっている可能性がある。
      • 悪い例:VERITAS Backup Execなので”V” → Symantec Backup Execになっちゃった…。
      • 良い例:役割がBackupなので”B”
  • プロジェクト名
    • つけがちだが、数年後にサーバー増設プロジェクトが発生した場合、同じ役割のサーバーの命名ルールが分断される。

要素の命名順番

サーバー名をアルファベット順に並び替えた時にどうなるかに着目すると、システム名を一番最初に持ってくるのが良いと思われる。良くあるのがサイト名を最初に持ってくるシステムだが、こうするとGUIでアルファベット順に並び替えた時に同じシステムの同役割のサーバーが分断されてしまい、作業ミスが発生しやすくなる。全部CUIでやるからいい、という人もいるかもしれないが、月次レポートなどでExcelでデータ出力する際に、同じ役割のサーバーが別々で表示されるのでストレスがたまると思う。