ช่องโหว่ด้านความปลอดภัยใน Azure Pipelines?

Aug 16 2020

ฉันได้ทำการค้นคว้าเกี่ยวกับ Azure DevOps และฉันได้พบกับสิ่งที่ดูเหมือนช่องโหว่ด้านความปลอดภัยที่ชัดเจนในท่อ Azure

ดังนั้นฉันกำลังสร้างไปป์ไลน์ของฉันเป็น YAML และกำหนด 2 ขั้นตอน: ขั้นตอนการสร้างและขั้นตอนการทำให้ใช้งานได้ ขั้นตอนการปรับใช้มีลักษณะดังนี้:

- stage: deployApiProdStage
  displayName: 'Deploy API to PROD'
  dependsOn: buildTestApiStage
  jobs:
  - deployment: deployApiProdJob
    displayName: 'Deploy API to PROD'
    timeoutInMinutes: 10
    condition: and(succeeded(), eq(variables.isRelease, true))
    environment: PROD
    strategy:
      runOnce:
        deploy:
          steps:
          - task: AzureWebApp@1
            displayName: 'Deploy Azure web app'
            inputs:
              azureSubscription: '(service connection to production web app)'
              appType: 'webAppLinux'
              appName: 'my-web-app'
              package: '$(Pipeline.Workspace)/$(artifactName)/**/*.zip'
              runtimeStack: 'DOTNETCORE|3.1'
              startUpCommand: 'dotnet My.Api.dll'

เอกสารของ Microsoft พูดถึงการรักษาความปลอดภัยโดยการเพิ่มการอนุมัติและการตรวจสอบสภาพแวดล้อม ในกรณีข้างต้นคือสภาพแวดล้อมของ PROD สิ่งนี้จะดีถ้าทรัพยากรที่ได้รับการป้องกันในที่นี้ซึ่งอนุญาตให้เผยแพร่ไปยังแอปพลิเคชันเว็บ PROD ของฉัน - การเชื่อมต่อบริการใน azureSubscription - ถูกดึงออกจากสภาพแวดล้อม PROD น่าเสียดายที่ฉันสามารถบอกได้ว่ามันไม่ใช่ มันเกี่ยวข้องกับไปป์ไลน์แทน

ซึ่งหมายความว่าเมื่อมีการเรียกใช้ไปป์ไลน์ครั้งแรก UI ของ Azure DevOps จะแจ้งให้ฉันอนุญาตการเข้าถึงไปป์ไลน์เพื่อเชื่อมต่อบริการซึ่งจำเป็นสำหรับการปรับใช้ใด ๆ ที่จะเกิดขึ้น เมื่ออนุญาตการเข้าถึงไปป์ไลน์นั้นจะสามารถเข้าถึงการเชื่อมต่อบริการนั้นได้ตลอดไป ซึ่งหมายความว่านับจากนั้นเป็นต้นไปการเชื่อมต่อบริการนั้นสามารถใช้ได้ไม่ว่าจะระบุสภาพแวดล้อมใดสำหรับงานก็ตาม ยิ่งไปกว่านั้นชื่อสภาพแวดล้อมใด ๆ ที่ระบุซึ่งไม่รู้จักจะไม่ก่อให้เกิดข้อผิดพลาด แต่ทำให้สภาพแวดล้อมว่างถูกสร้างขึ้นโดยค่าเริ่มต้น!

ดังนั้นแม้ว่าฉันจะตั้งค่าการอนุมัติด้วยตนเองสำหรับสภาพแวดล้อม PROD หากมีคนในองค์กรจัดการเปลี่ยนแปลงผ่านการตรวจสอบโค้ดของเรา (ซึ่งเป็นไปได้ด้วยการตรวจสอบโค้ดขนาดใหญ่เป็นประจำ) ที่เปลี่ยนชื่อสภาพแวดล้อมเป็น 'NewPROD' ในสีฟ้า -pipelines.yml ไฟล์ CI / CD จะสร้างสภาพแวดล้อมใหม่นั้นและดำเนินการต่อและปรับใช้กับ PROD ทันทีเนื่องจากสภาพแวดล้อมใหม่ไม่มีการตรวจสอบหรือการอนุมัติ!

แน่นอนว่ามันจะสมเหตุสมผลสำหรับการเชื่อมต่อบริการที่จะเชื่อมโยงกับสภาพแวดล้อมแทน นอกจากนี้ยังควรมีตัวเลือกในการห้ามการสร้างสภาพแวดล้อมใหม่โดยอัตโนมัติ - ฉันไม่เห็นว่าจะมีประโยชน์อย่างไรโดยเฉพาะ ตอนนี้เท่าที่ฉันสามารถบอกได้นี่เป็นช่องโหว่ด้านความปลอดภัยขนาดใหญ่ที่สามารถทำให้การปรับใช้กับสภาพแวดล้อมที่สำคัญโดยทุกคนที่ยอมให้เข้าถึง repo หรือจัดการเพื่อส่งการเปลี่ยนแปลงไปยังไฟล์ azure-pipelines.yml ผ่านกระบวนการอนุมัติ แนะนำจุดสำคัญจุดเดียวของความล้มเหลว / จุดอ่อน เกิดอะไรขึ้นกับวิธีการที่เพิ่มมากขึ้นในการรักษาความปลอดภัยไปป์ไลน์ของคุณ? ฉันพลาดอะไรบางอย่างที่นี่หรือช่องโหว่ด้านความปลอดภัยนี้ไม่ดีเท่าที่ฉันคิด?

คำตอบ

1 CeceDong-MSFT Aug 17 2020 at 16:04

ในตัวอย่างของคุณดูเหมือนว่าคุณสร้าง / ใช้สภาพแวดล้อมที่ว่างเปล่าไม่มีเป้าหมายการปรับใช้ ปัจจุบันเฉพาะทรัพยากร Kubernetesและประเภททรัพยากรเครื่องเสมือนเท่านั้นที่ได้รับการสนับสนุนในสภาพแวดล้อม

https://docs.microsoft.com/en-us/azure/devops/pipelines/process/environments?view=azure-devops

ทรัพยากรในตัวอย่างของคุณคือการเชื่อมต่อบริการดังนั้นคุณต้องไปที่การเชื่อมต่อบริการและกำหนดการตรวจสอบสำหรับการเชื่อมต่อบริการนี้