Azure DevOps Sprint 207リリースノートの翻訳を行いました。オリジナルはこちらからご覧ください。
今回はほとんどセキュリティ関係の修正、エージェントプールの非推奨もしくは廃止の話ですね。今まで特に古いクラッシックパイプラインで過剰な権限を持っていたのでちゃんと制限するようにした、という習性が多いですね。クラッシックなので廃止する方向なのかと思っていましたが、まだまだ使っている人多いのでしょうか。
macOS 10.15のエージェントプールを使っている人は移行予告の意図的な停止があるので、このスケジュールにあたってビルドに失敗した人は早めに移行しましょう。スクリプトも提供されているのでチェックもできますね。
今回は簡単ですが、また三週間後。
KDDIさんの会見そのものは未視聴ですが、会見ではこんな話があったそうで。
吉村氏「手順書が2種類あった。対象となるルーターの手順書だったが、ルーティングポリシーの変更があり、手順書の変更が発生。新しい手順書を使わなければならなかったのが古い手順書を使ってしまった。管理の問題。」
— 小山安博 Yasuhiro Koyama (@surblue) 2022年7月29日
「必ず承認作業があり、手順書の最新ファイルかどうかを確認したが、中身が誤っていたので、承認で気付かなかった。承認の手法、手順の何が差分があるか、目検だけでなくシステムで確認できるように精度を上げていきたい。」
— 小山安博 Yasuhiro Koyama (@surblue) 2022年7月29日
※ この話だけを取り上げるのでスレッドの一部だけですが、一連の話も読んでください
この話を知人にしたら「クラウドに置いているのは最新、ということだけどそれでは困っているという人がいる」ということでこの話を紹介されました。
Googleドライブの中にWordを置くと、Googleドキュメントに変換されるが、同時編集でなくても、自分以外の人がスペースを入れても、句点「。」を打ってもすぐに上書きされてしまう。 Microsoft製品だと、Teams（チームス）やSharepoint（シェアポイント）でデータを共有するが、これまたほんの些細な変更でもどんどん上書きされていってしまう。 こういうクラウド上にデータを置いて共同作業する これをある組織では「タイトル（常に最新）」という名前の付け方をされている。 たとえば、「天野公演説明プレゼン（常に最新）」といった感じだ。 作業内容が保存されずに消えないことはありがたいが、大勢で寄ってたかって編集して、 ”いやいや、そこは元のままで正しかったのに”とか ”誰じゃー、これ勝手に変えたのはーっ” ということも起きる。
Microsoft 365付属のOfficeではOneDriveに保存している場合、自動保存がデフォルトでONになります。
失敗してもCtrl+zで戻せばいいですが、「だいぶ前に戻したい」というときはこの履歴を使うのが便利です。
無制限に戻せるわけではなく、会社などでは設定した上限までです。
とはいえ、私の場合この機能常時使っていなくて、ドキュメントの構成を作って書く内容を大雑把に決めるところまでは自動保存をオフにしておいて、適宜Ctrl+Sで保存。これで内容的に満たしたからここから肉付けしようか、という段階になってから自動保存をONにします。まぁ大体習慣的なものというか。
上のお話のように「みんなで」ドキュメントを作り上げる場合、共同編集機能でドキュメントに招待します。
私の場合、どこに置くかはこうしています。
この「ノボちゃん」のブログ主は「みんなに勝手に編集されて困る」という話ですが、それはちょっとやり方が違うんじゃないかなと思います。
ちゃんとコメントはmentionも飛びます。今のOfficeはコメントを「解決」状態にできるので、コメント解決し忘れているところは未修正箇所ですね。ただ、Officeドキュメントだけだったら自分のタスクとして覚えられない、ということもあると思います。
そういう時はOneNoteを共有して、ドキュメントをリンクノートとして追加します。
この辺が図入りでもう少し分かりやすいかな。
ただこれでもOneNoteを忘れたらだめですよね。そういう時はOutlookタスクとして設定します。
Outlookタスクは自動的にMicrosoft To Doのタスクとして登録されるので、Outlook, OneNote, To Do, Teams(のタスク)どれを開いても自分のタスクが確認可能です。
どうでもいい話：
これ昔 SharePoint 2007から2013までの時代、OneNote→SharePoint→Outlookとタスク一気通貫でできるかなぁと夢見たことあったんですよ。残念ながら当時はOutlook→OneNoteかOneNote→SharePointといった1ホップしかできなくてあきらめていたんですが、クラウドサービスになってやっと、という感じです。
まぁこうやって、同期（同じ場所、同じ時間）で一緒に作り上げるフェーズと非同期（思いついたときに）のフェーズでやり方を変えないと、余計な手間ばかりかかります。
どうしても編集させたくないのであれば明示的にチェックアウトすればほかの人が編集できなくなります。
でもKDDIのように承認があるドキュメントだとどうするの？ということであれば、Power Automateで承認のワークフローを作って承認依頼ドキュメントリストに入れたら承認実施する、ということになるでしょうね。
承認されたドキュメントは承認済みへコピー/ 移動して常時そこのファイルを参照すればいいんじゃないでしょうか（もちろん編集権限はみんななし）。
たくさんの方に視聴・ご参加いただきありがとうございました。ちょっとうっとうしいTeams参加通知を消す編集に手間取りました。
資料はこちら。
中村さんに作っていただいたプロジェクトはパブリックなのでいつでも見えます。貴重な事情を赤裸々に語っていただいてありがとうございました。参加してコメントいただいた皆さんもありがとうございました。ちょっと不手際でロビー待ちになっていたり、なかなか入れなかったりとすいません。録画にも出てしまっていたので、少し編集でごまかしています。
大きなカンファレンスでは割とキラキラした事例が多く、「うちは大丈夫なのか」と焦ることも多いと思いますが、そうじゃないところもまだまだ多いはずなので、安心して（？）少しずつでも改善していきましょう。
Microsoft 製のファジング テスト フレームワーク "OneFuzz" という便利なものがあるのだが、あまり知られていない..。実は、CI/CD 連携も、WIT 連携もしてくれる。ただ、セルフホスト型なので気軽には使えないのが玉に瑕。#tfsughttps://t.co/ixEmI0MqUJ
— azukipochette (@azukipochette) 2022年7月26日
Azure Pipelines でパッケージで脆弱性を検出するのは、"dotnet list package --vulnerable --format json" で json 出力して jq コマンドで解析してエラーの場合はパイプライン失敗させる、というのは比較的簡単に実装できそうな気がする。UI が欲しいなら SARIF に変換するのが良さそう。 #tfsug
— azukipochette (@azukipochette) 2022年7月26日
知らなかったです。ありがとうございます。
GitHub Actions / Azure Pipelinesで使われているイメージを作成するためのレポジトリはこちら。
Windowsのイメージだと6時間少々、Ubuntuだと2時間ちょっとでできるはずです。私はこのレポジトリをforkしてカスタマイズして不要なもの（古い.NET Coreや不要なDockerイメージ）とかを削っています。時間がかかるのでCIする場合、Hostedでは作れないので、selfhost用のイメージを作るにはまずローカルで作ってからになります。
モバイルのCI/CDに特化したサービスであればVisual Studio App Centerがあります。これもバックエンドはAzure Pipelines / GitHub Actionsと同じです。CIするなら楽なんですが、最近サービス更新がちょっとされていないように見えるので現時点ではActions / Pipelinesを使ったほうがいいかもしれません。
一応ロードマップには「技術的負債が結構あり、対応しんどいけど、頑張っています」的なことが書かれています。
Azureサブスクリプションで使えるのでお支払い的には便利です。
あと、パブリックにしていいものとか、歴史的事情でAzure Reposにあるけど、GitHubにも課金しているという人であればAzure Reposから定期的にGitHubへpushしてGitHubのDependabotに任せるという意見もありました😅。
一応こういうやり方もあるよという話です。
請負で直接指示できないような場合、やはりプロジェクトを跨いだforkをするのがいいんじゃないかという話です。タスク管理もお互いでできるので割と要件を満たせると思います。
今回の配信はAzure Rock Starプログラムの支援をいただいています（セッション中いうの忘れていたので宣伝）。ありがとうございました。
Azureにはいろんなサービスがあるので未経験の人が使いはじめるのはなかなか難しくなってきました。特に初学者向けの研修といえばVM作るあたりから始めるのは仕方ないものの、それだけで本番作るとちょっと困る。そして最近新しく始める人からよく「これだけやっておけばいいよ」というものない？という相談を受けることが多くなりました。どんな要素を押さえておかないといけないかなぁ？ということでつらつらとまとめてみます。忘れているものとかあれば教えてください。
クラウド移行するためのフレームワークです。技術的な話だけではなく、組織やセキュリティの定義を決めましょうというような話をフレームワークとしてまとめられています。
クラウドは日進月歩です。日々ベストプラクティスは更新されています。そういう視点でコスト、セキュリティ、信頼性、運用容易性、パフォーマンス効率といった観点でどうやって運用するつもりであるかというチェックリストです。
使う技術を選んだらMicrosoft Learnで基本的な学習をお勧めします。新しく入ったメンバーに技術要素を学んでもらうためにもお勧めです。個人用Microsoftアカウントを使えばどこまで学習したか記録してくれて、無料で実際のAzure環境を使った演習ができる内容もあります。
Azureも計画的なメンテナンス、重大な性能低下、非互換を伴う仕様変更といったことがちょこちょこ起きます。そういった情報を通知してくれます。サブスクリプションごとに設定しなければなりません。モバイルアプリへの通知、Webhookを使用して外部のシステムに通知する、メール通知するといったことも可能です。
AzureのID管理はAzure ADです。とりあえずこれを理解しないと始まりません。組織の既存のIDシングルサインオンをするもよし、独自のIDにしてもいいですが…めんどくさいです。ユーザーだけではなくEndpoint ManagerやMicrosoft 365 Defenderと連携することでデバイスの制御もできるようになります。例えばポータルにアクセスするにはAzure ADに参加しているデバイスで最新のパッチが適用されていなければならないというポリシーの設定も可能です。
Azure ADは一定以下のオブジェクト（ユーザー、グループなど）であれば無料で使えますが、一定以上のセキュリティ機能を使おうとすると有償ライセンスを検討します。
Azure AD PremiumはEnterprise Mobilityにも付属するライセンスなので通常組織内のデバイスセキュリティを考えると別途用意するまでもなく「用意するもの」かなと思います。気にするのは組織外から招待した協力会社のアカウントでしょうね。
Azure ADのライセンスはテナントごとなので、例えばAzureアプリケーションをセキュリティのため別テナントにしよう！という考えでテナントわけてしまうと、新規テナント用にAzure AD Premiumライセンスが別途かかりますので気を付けてください。
多要素認証MFAは新しく作られたテナントなら初期設定されているので、明示的に無効にしない限りアプリ通知は使えるので、スマートフォンもしくは類するデバイスを用意しましょう。
セキュリティの指標としてIDセキュリティ スコアという機能が提供されています。こちらを見て、継続的に改善してください。
Azure ADのグループやセキュリティのほかにRBACの理解が必要です。例えば「VMのモニタリングはできるが起動・停止はできない」という権限を作りたい場合、RBACを使わなくてはなりません。適当にやるとドはまりしてひどいことになるので、注意してください。Azure ADでグループを作って、そのグループに対して割り当てるという形になるでしょうね。
RBACは出来合いの組み込みロールがありますので、そこから不要なものを削っていく方向で作るのがおすすめです。
Azure ADの全体管理者などの特権ユーザーはAzure AD Premium P2を割り当てて、Azure AD Privileged Identity Managementで使用時の特権昇格するようにしましょう。
ただ、ドメインアカウントに割り当てたアカウントのみだとドメインが乗っ取られてしまった場合どうにもならなくなるので、onmicrosoft.comドメインのアカウントを緊急アカウントとして割り当てる必要があります。
(2022/7/25追記)
昔は特定のIDを作ってそれをアプリケーション専用に割り当てるなんてことをやっていた人も多かったと思います。典型的な例で言えばSQL DatabaseのSQL認証ですね。そういうIDを作ってしまうと総当たりでやられることがあります。
マネージドIDの使用を検討しましょう。こちらもプライベートリンクリソース同様にプレビューやGA直後はサポートしていないサービスがあったりするので、使えるかどうか確認してからということになります。
ネットワークはどうしても理解しておかないといけないものですね。とりあえずPrivate EndpointとPrivate Linkは理解しておかないと閉域網作れません。パブリックなサービスだからといっても、データベースがインターネットからアクセス可能にしておくということはないですしね。
データを格納するPaaSを選ぶ場合プライベート リンクリソースに載っているものから選びましょう。プレビュー時点ではサポートしていないものも多いですし、そもそも高いSKUじゃないとプライベート リンクをサポートしないものも多いので、課金にも注意です。
マネージド管理するならまずはAzure Monitorから。Elasticソリューションに慣れた人にはElastic on Azureなんてものもありますね。
診断や監視するのはいいですが、Azure Monitorの料金は読みづらいもののひとつです。サンプリングして料金を計測していくしかないですね😅。
Log Analyticsという名前も若干悪いと思っていますが、中身はデータウェアハウスなのでほっとくと馬鹿みたいにコストが上がります。要件上の理由で保存が必要なら定期的にエクスポートしましょう。
とりあえずStandardを購入してサブスクリプション全体に適用してしまいましょう（暴言）。経験の少ない人でも設定ミスがだいぶ減らせます。例えば既定でSQL DatabaseはAzure内のどこからでもアクセスできます。そういう設定を検出してくれます。セキュアスコアを順次改善しましょう。
「ｘｘをやってはいけない」といわれても覚えていられないし、やってしまうことはあります。そういうことをできなくするのがAzure Policy。検証向けのサブスクリプションで評価して、本番向けのサブスクリプションに適用していくのがいいのでしょうね。
ただ、純粋な開発環境でそこまで不要で例えば「東日本にこのサイズのVMまでしか作ったらだめですよ」という制限したいだけならAzure Dev Test Labsでも用が済むかもしれませんね。SLAがない代わりに安いですし。
(2022/7/25追記）
docs.microsoft.com
コスト意識も重要です。AzureにはCost Managementという機能もあるので、詳細な分析をしてみてください。ポータル触らせたくないけどコストは見せたいという場合、Power BIとの連携もできます。
(2023/3/1 追記)
github.com
日本法人の方々が作られた資料をまとめたインデックスページです。learnのコンテンツ以外の情報もあるので、自分が使う範囲の参考に。
FastTrack for Azure(Azure移行支援)の方々のノウハウをまとめられた資料だそうです。移行するときはまずこれも軽く見るといいでしょう。
Azure App Serviceのセキュリティ脅威への対策ガイド。使う人はまず読みましょう。
