kkamegawa's weblog

Visual Studio,TFS,ALM,VSTS,DevOps関係のことについていろいろと書いていきます。Google Analyticsで解析を行っています

Azure DevOpsのビルド時に各種セキュリティ/credentialスキャンを実施する

GitHubにシークレットキーをプッシュするとすぐにGitHubのBotから「まちがえてpushしてない?」という通知が来るのはよく知られた話です。あと、最近ではセキュリティスキャンもやってくれるようになりましたね。Azure DevOpsにはないのでしょうか?実はエンタープライズ向けには簡単なものですが、用意されています。

secdevtools.azurewebsites.net

対象者

Microsoft Security Code Analysis Extensionという拡張機能なのですが、これ実は一般のMarketplaceには出てきません。以下のサポート契約を持っているorganizationで申請すれば出てきます。お近くのTAM(テクニカルアカウントマネージャー)に相談してみてください。

  • Unified Support Advanced tier
  • Unified Support Performance tier
  • Premier Support for Developers
  • Premier Support for Partners
  • Premier Support for Enterprise

docs.microsoft.com

私はちょっと有効化してもらったので、紹介したいと思います。とはいえ、ひとつの拡張機能を除いてほとんどオープンソースで提供されているので、タスクがあらかじめある、という程度のものなのですが。

注意点

いくつかのタスクは Build.StagingFolderに対して実行します。なので、これらのスキャナを実行する前にCopy FolderタスクでStaging Folderへコピーしてからじゃないと空振りします。

私はWindows DefenderとかはBuild.SourceFolderに対してかけるようにしました。

実行結果

f:id:kkamegawa:20200226065751p:plain

実行するとPiplelineのoutput, CSV, HTMLといった形式で出力されます。結果をAzure Artifactsへの発行もできるので、履歴として保持もできます。通常は

f:id:kkamegawa:20200226065855p:plain

Artifactsにはこんな感じで入っています。マルウェア検査とRoslyn Analyzerの結果ですね。

静的コード解析

f:id:kkamegawa:20200226063746p:plain

Roslyn AnalyzerとTSLintが含まれます。前者は.NETのコードの静的解析、後者はTypeScriptのコード解析です。TSLintについてはご存知の方も多いと思います。

- task: RoslynAnalyzers@2
  inputs:
    userProvideBuildInfo: 'auto'

YAMLタスクは簡単ですね。

セキュリティ関係

f:id:kkamegawa:20200226063739p:plain

一番上は別途申請しないと使えないMicrosoft Security Risk Detectionです。マルウェアスキャンではなく、ふるまいを検査するEDR…のようです。

docs.microsoft.com

こちらをご覧ください。

申請すると、アクセスするためのキーとアカウントが発行されますので、それがないと使えません。興味のある人はサインアップページから英語で問い合わせてください。

www.microsoft.com

Post Analysis, Publish~, Reportの3タスクは最後に動かしてください。

スキャナ

f:id:kkamegawa:20200226063743p:plain

AntiMalware ScannerはWindows Defenderを動かしてバイナリスキャンをします。注意点として、hosted agentではユーザー制御による更新が禁止されているので、定義ファイルの更新はできないので、無効化します。

- task: AntiMalware@3
  inputs:
    InputType: 'Custom'
    Arguments: '-Scan -ScanType 2 -DisableRemediation -path $(Build.SourceDirectory)\bin'
    EnableServices: true
    SupportLogOnError: false
    TreatSignatureUpdateFailureAs: 'Warning'
    SignatureFreshness: 'UpToDate'
    TreatStaleSignatureAs: 'Error'

YAMLだとこんな感じ。実はこれ、Windows Defenderをコマンドで動かしているだけなので、このオプションがそのまま使えます。

docs.microsoft.com

BinSkimはGitHubにソースもありますので、ここからダウンロードして実行してもいいでしょう。

github.com

Credential Scannerはこんな感じです。

- task: CredScan@2
  inputs:
    verboseOutput: true

MSRDに関してはアクティベーションできたらまた別途試してみます。

Azure DevOps Server 2019でAzure SQL Databaseを使う

オンプレミスのAzure DevOps ServerはSQL Serverとペアで使います。大体直近2バージョンくらいまでサポートしているはずです。現在のAzure DevOps Server 2019 Update 1.1でSQL Server 2019をサポートしています。ただし、Windows版のみで、Linux版はサポートされません。

docs.microsoft.com

今までのオンプレミスのSQL Serverだけではなく、Azure DevOps Server 2019ではAzure SQL Databaseがサポートされるようになりました。

docs.microsoft.com

ちょっと制限がありますが、データベースがメンテナンスフリーになるのは非常に魅力的です。インストール時の注意点についてまとめます。

前提条件

  • デプロイ時にManaged Service IDを有効にしなくてはならない
  • Azure ADとフェデレーションしているドメイン環境にいなくてはならない
  • SQL DatabaseはConfigurationとCollectionをそれぞれシングルインスタンスのみサポート。Managed Instanceやエラスティックプールは未サポート
  • SQL DatabaseはStandard S3以上のSKUでなくてはならない

Standard S3以上ってのは検証のために用意するのはなかなかきついですね。ただし、SQL Server Reportingおよび、SQL Server Analysis Servicesはサポートされないので、Azure DevOps Server 2019内蔵のAnalyticsを使ってください。

ドメインに関してはドキュメントにはAzure Virtual Machines that are domain joined.とあるのですが、どうもAADDSに参加しているだけではダメで、Azure ADとフェデレーションしていないといけないようです。

f:id:kkamegawa:20200225062647p:plain

Managed IDはここですね。オンになってないといけません。

データベース作成

SQL Database作成はいいとして、二つのデータベースをStandard S3以上のSKUで作っておいてください。

  • AzureDevOps_Configuration
  • AzureDevOps_DefaultCollection

また、SQL DatabaseにはAzure Active Directory Authenticaitonを設定しておかないとセットアップできません。

データベース権限設定

ssmsでmasterデータベースを開いて、以下のクエリを実行します。

CREATE USER [VMName] FROM EXTERNAL PROVIDER
ALTER ROLE [dbmanager] ADD MEMBER [VMName]

[VMName]はAzureでのVM名(Start-azvm-name引数に指定する値)で、DNS名ではありません。

次にCollectionおよび、Configuration Database(AzureDevOps_ConfigurationとAzureDevOps_DefaultCollection)すべてに対して以下のSQLを実行します。

CREATE USER [VMName] FROM EXTERNAL PROVIDER
ALTER ROLE [db_owner] ADD MEMBER [VMName]
ALTER USER [VMName] WITH DEFAULT_SCHEMA=dbo

VMNameはさっきと一緒です。

インストール

f:id:kkamegawa:20200225065753p:plain

サーバー構成ウィザードのところで新しい配置 - Azureを選んでください。あとはコレクション名をDefaultCollectionのまま変更しなければいけるはずです…。

と紹介できればよかったのですが、フェデレーションしてる環境持ってないので、ここまでの紹介です(ごめん)。

これは新規インストールですが、アップグレードする際は「既存のデータベースがあります」を途中で選べばいいです。

Azure DevOps 2020/2/17の更新

Azure DevOps Sprint 165リリースノートの翻訳を行いました。オリジナルはこちらからご覧ください。

docs.microsoft.com

今回も小幅な更新で、三週間ごとのスプリント出るんだろうかとヤキモキしていたんですが、なんとか出たようです。

最大の更新は結構期待されていたYAMLパイプラインを実行せずにパースできるプレビューモードが実装されました。現在はREST叩かないといけないようですが、エディターでもサポートされるようになるとのことです。これは助かりますね。

ホストプール単位でエージェントの更新をしたくないという要件はごく一部ですがあると嬉しいのかと思います。書かれているように、基本的にはこれ無効にしないことをおすすめします。ちょいちょいバグ直ってますし。

ではまた三週間後(に公開されるといいなぁ)。

Translate to Japanese to Azure DevOps release note ...

プライベートで作ったAzure Artifactsフィードをほかのプロジェクトで参照したい

Azure Artifactsに関してこんな相談を受けました。

返信で回答しており、できたということなんですが、一応備忘録的に書いておきます。

まず、Azure Artifactsには全世界に見えるPublic、Organization、Projectといった三段階のスコープがあります。やったことはないですが、Publicにしても例えばAzure の条件付きアクセスポリシーを設定してしまえば、「社員(事務所など)からはみえるんだけど、一般の人には見えない」なんてArtifactsフィードもできるのかな。これできたらちょっと便利なケースがありそうですが。条件付きアクセスポリシーの対象外になるのかなーどうかなー。

f:id:kkamegawa:20200216213202p:plain

Active FeedsとDeleted Feedsの二種類があります。さらにProject(Testfeed)とOrganization(internal_pre_publishとlocalMaven)レベルですね。

f:id:kkamegawa:20200216213206p:plain

Deleted Feedsに切り替えるとゴミ箱に入れたフィードが表示されます(入れてないので空です)。さて、このProjectのフィード(TestFeed)はよそのチームプロジェクトからは参照できません。しかし、昔はArtifactsのスコープがProjectしかなかったので、その経緯でProjectのままになっているとか、あとから見せたくなったとか、理由で参照させたいことはあります。

f:id:kkamegawa:20200216213214p:plain

そういうときはClassicの場合、ビルド定義でBuild job authorization scopeProject Collectionにしてください。Collectionってなんやねん、と思われるかもしれませんが、現在のOrganizationのことです。Organizationという名前があとからできてしまったので、整合が取れて無いですね…。Azure DevOps Server 2019ではCollectionでいいのですが。

f:id:kkamegawa:20200216213219p:plain

え、おれのビルド定義もうYAMLしか書いてないけど、そんなのないよ?どうやるの?という方もいると思います。

f:id:kkamegawa:20200216213210p:plain

そういう場合、ProjectのPipelinesSettingsにあるLimit job authorization scope to current projectを設定します。有効にするとジョブは現在のプロジェクトのみです。スクリーンキャプチャはOrganizationレベルの設定なので、こちらを設定すると全プロジェクトはプロジェクト外のリソースにはアクセスできなくなります。

この設定はビルド管理者の権限が必要になるのと、有効にしてしまうとほかのプロジェクトのリソースに簡単に参照できるようになるので、気を付けてください。

過去のフィードは致し方ないのですが、Artifactsは基本的にOrganizationレベルで作ることをお勧めします。ここが一番大きなセキュリティの分界点です(というお話をIgnite The Tourでもさせていただきました)。