Trong bài viết này, tôi sẽ hướng dẫn bạn cách thêm một bước phê duyệt thủ công vào AWS Cloud Development Kit (CDK) Pipelines để xác nhận các thay đổi bảo mật trước khi triển khai. Với giải pháp này, khi một nhà phát triển thực hiện một thay đổi, CDK pipeline sẽ xác định một sự thay đổi quyền IAM, tạm dừng quá trình thực thi và gửi thông báo cho một kỹ sư bảo mật để phê duyệt hoặc từ chối thay đổi trước khi nó được triển khai.
Giới thiệu
Trong vai trò của tôi, tôi đã nói chuyện với rất nhiều khách hàng thích thú với AWS Cloud Development Kit (CDK). Một trong những điều họ thích là các construct L2 thường tạo ra các chính sách IAM và bảo mật khác. Điều này có thể tiết kiệm rất nhiều thời gian và công sức so với việc viết mã chính sách thủ công. Hầu hết khách hàng cũng cho tôi biết rằng các chính sách được tạo ra bởi CDK thường an toàn hơn so với những chính sách họ tạo ra thủ công.
Tuy nhiên, những khách hàng này cũng lo lắng rằng đội ngũ kỹ sư bảo mật của họ không biết chính sách CDK tạo ra có gì. Trong quá khứ, những khách hàng này đã dành rất nhiều thời gian để tạo ra một số ít chính sách IAM mà các nhà phát triển có thể sử dụng trong ứng dụng của họ. Những chính sách này được hiểu rõ, nhưng quá cho phép do thường được sử dụng lại trong nhiều ứng dụng khác nhau.
Khách hàng muốn có thêm khả năng xem xét các chính sách mà CDK tạo ra. May mắn thay, CDK cung cấp một cơ chế để phê duyệt các thay đổi bảo mật. Nếu bạn đang sử dụng CDK, bạn có thể đã nhận được lời mời phê duyệt các thay đổi bảo mật khi bạn chạy cdk deploy tại dòng lệnh. Điều này hoạt động tốt trên máy của một nhà phát triển, nhưng khách hàng muốn tích hợp cùng xác nhận này vào luồng triển khai liên tục của họ. CDK cung cấp một cơ chế cho điều này với hành động ConfirmPermissionsBroadening. Lưu ý rằng ConfirmPermissionsBroadening chỉ được hỗ trợ bởi máy triển khai AWS CodePipeline.
Lịch sử
Trước khi tôi nói về ConfirmPermissionsBroadening, hãy để tôi xem xét cách CDK tạo chính sách IAM. Hãy xem xét ứng dụng “Hello, CDK” được tạo trong AWS CDK Workshop. Cuối module này, tôi có một hàm AWS Lambda và một Amazon API Gateway được xác định bằng mã CDK sau đây.
// xác định một tài nguyên AWS Lambda
const hello = new lambda.Function(this, ‘HelloHandler’, {
runtime: lambda.Runtime.NODEJS_14_X, // môi trường thực thi
code: lambda.Code.fromAsset(‘lambda’), // mã được tải từ thư mục “lambda”
handler: ‘hello.handler’ // tên file là “hello”, tên hàm là “handler”
});
// xác định một tài nguyên API Gateway REST API được hỗ trợ bởi hàm “hello” của chúng tôi.
new apigw.LambdaRestApi(this, ‘Endpoint’, {
handler: hello
});
Lưu ý rằng tôi không cần phải xác định IAM Role hoặc Quyền Lambda. Tôi chỉ cần truyền một tham chiếu đến hàm Lambda cho API Gateway (dòng 10 ở trên). CDK hiểu tôi đang làm gì và đã tạo ra các quyền cho tôi. Ví dụ, CDK đã tạo ra Quyền Lambda sau đây, bao gồm các quyền khác.
{
“Effect”: “Allow”,
“Principal”: {
“Service”: “apigateway.amazonaws.com”
},
“Action”: “lambda:InvokeFunction”,
“Resource”: “arn:aws:lambda:us-east-1:123456789012:function:HelloHandler2E4FBA4D”,
“Condition”: {
“ArnLike”: {
“AWS:SourceArn”: “arn:aws:execute-api:us-east-1:123456789012:9y6ioaohv0/prod/*/”
}
}
}
Lưu ý rằng CDK đã tạo ra một chính sách với phạm vi hẹp, cho phép một API cụ thể (dòng 10 ở trên) gọi một hàm Lambda cụ thể (dòng 7 ở trên). Chính sách này không thể tái sử dụng ở nơi khác. Sau đó trong cùng workshop, tôi đã tạo một Construct Hit Counter bằng cách sử dụng một hàm Lambda và một bảng Amazon DynamoDB. Một lần nữa, tôi liên kết chúng bằng một dòng mã CDK duy nhất.
table.grantReadWriteData(this.handler);
Như trong ví dụ trước, CDK đã tạo ra một chính sách IAM với phạm vi hẹp. Chính sách này cho phép hàm Lambda thực hiện các hành động cụ thể (dòng 4-11) trên một bảng cụ thể (dòng 14 bên dưới).
{
“Effect”: “Allow”,
“Action”: [
“dynamodb:BatchGetItem”,
“dynamodb:ConditionCheckItem”,
“dynamodb:DescribeTable”,
“dynamodb:GetItem”,
“dynamodb:GetRecords”,
“dynamodb:GetShardIterator”,
“dynamodb:Query”,
“dynamodb:Scan”
],
“Resource”: [
“arn:aws:dynamodb:us-east-1:123456789012:table/HelloHitCounterHits”
]
}
Như bạn có thể thấy, CDK đã thực hiện rất nhiều công việc cho tôi. Hơn nữa, CDK đang tạo ra các chính sách với phạm vi hẹp cho mỗi tài nguyên, thay vì chia sẻ một chính sách với phạm vi rộng trong nhiều vị trí khác nhau.
Kiểm tra Quyền CDK Pipelines
Bây giờ sau khi tôi đã xem xét cách CDK tạo chính sách, hãy thảo luận về cách tôi có thể sử dụng điều này trong một luồng triển khai liên tục. Cụ thể, tôi muốn cho phép CDK tạo chính sách, nhưng tôi muốn một kỹ sư bảo mật xem xét bất kỳ thay đổi nào bằng cách sử dụng bước phê duyệt thủ công trong luồng triển khai. Tất nhiên, tôi không muốn bảo mật trở thành một nút cổ chai, vì vậy tôi chỉ yêu cầu phê duyệt khi các câu lệnh bảo mật hoặc quy tắc lưu lượng được thêm vào. Luồng triển khai sẽ bỏ qua bước phê duyệt thủ công nếu không có quy tắc bảo mật mới được thêm vào.
Hãy tiếp tục sử dụng CDK Workshop như một ví dụ. Trong module CDK Pipelines, tôi đã sử dụng CDK để cấu hình AWS CodePipeline để triển khai ứng dụng “Hello, CDK” mà tôi đã thảo luận ở trên. Một trong những việc cuối cùng tôi thực hiện trong workshop là thêm một bài kiểm tra xác nhận bằng cách sử dụng bước sau triển khai. Thêm một kiểm tra quyền tương tự, nhưng tôi sẽ sử dụng một bước trước triển khai để đảm bảo kiểm tra quyền xảy ra trước khi triển khai.
Đầu tiên, tôi sẽ nhập ConfirmPermissionsBroadening từ gói pipelines
import {ConfirmPermissionsBroadening} from “aws-cdk-lib/pipelines”;
Sau đó, tôi có thể dễ dàng thêm ConfirmPermissionsBroadening vào deploySatage bằng cách sử dụng phương thức addPre như sau.
const deploy = new WorkshopPipelineStage(this, ‘Deploy’);
const deployStage = pipeline.addStage(deploy);
deployStage.addPre(
new ConfirmPermissionsBroadening(“PermissionCheck”, {
stage: deploy
})
deployStage.addPost(
// Đoạn mã kiểm tra sau triển khai bị bỏ qua
)
Sau khi tôi commit và push thay đổi này, một bước phê duyệt thủ công mới có tên PermissionCheck.Confirm sẽ được thêm vào giai đoạn Deploy của luồng triển khai. Trong tương lai, nếu tôi push một thay đổi thêm quy tắc bảo mật, luồng triển khai sẽ tạm dừng ở đây và chờ phê duyệt thủ công như được hiển thị trong ảnh chụp màn hình dưới đây.
Hình 1. Luồng triển khai chờ xem xét thủ công
Khi kỹ sư bảo mật nhấp vào nút xem xét, cô ấy sẽ thấy hộp thoại sau. Từ đây, cô ấy có thể nhấp vào URL để xem tóm tắt các thay đổi tôi yêu cầu, được ghi lại trong nhật ký xây dựng. Cô ấy cũng có thể chọn phê duyệt hoặc từ chối thay đổi và thêm ý kiến nếu cần.
Hình 2. Hộp thoại xem xét thủ công với liên kết đến nhật ký xây dựng
Khi kỹ sư bảo mật nhấp vào URL xem xét, cô ấy sẽ thấy tóm tắt về các thay đổi bảo mật như sau.
Hình 3. Tóm tắt các thay đổi bảo mật trong nhật ký xây dựng
Tính năng cuối cùng tôi muốn thêm là thông báo qua email để kỹ sư bảo mật biết khi cần phê duyệt. Để thực hiện điều này, tôi tạo một chủ đề Amazon Simple Notification Service (SNS) mới và đăng ký nó và gán với ConfirmPermissionsBroadening Check.
// Tạo chủ đề SNS và đăng ký cho phê duyệt bảo mật
const topic = new sns.Topic(this, ‘SecurityApproval’);
topic.addSubscription(new subscriptions.EmailSubscription(‘security-approvers@example.com’));
deployStage.addPre(
new ConfirmPermissionsBroadening(“PermissionCheck”, {
stage: deploy,
notificationTopic: topic
})
Với thông báo được cấu hình, kỹ sư bảo mật sẽ nhận được một email khi cần phê duyệt. Cô ấy sẽ có cơ hội xem xét các thay đổi bảo mật tôi đã thực hiện và đánh giá tác động của chúng. Điều này mang lại cho đội ngũ kỹ thuật bảo mật khả năng theo dõi họ muốn vào các chính sách mà CDK tạo ra. Ngoài ra, bước phê duyệt được bỏ qua nếu một thay đổi không thêm quy tắc bảo mật, vì vậy kỹ sư bảo mật không trở thành một điểm nút cổ chai trong quá trình triển khai.
Kết luận
AWS Cloud Development Kit (CDK) tự động tạo ra các chính sách IAM và các chính sách bảo mật khác. Điều này có thể tiết kiệm rất nhiều thời gian và công sức, nhưng đội ngũ kỹ thuật bảo mật muốn xem xét các chính sách mà CDK tạo ra. Để giải quyết điều này, CDK Pipelines cung cấp hành động ConfirmPermissionsBroadening. Khi bạn thêm ConfirmPermissionsBroadening vào luồng CI/CD của bạn, CDK sẽ đợi phê duyệt thủ công trước khi triển khai một thay đổi bao gồm các quy tắc bảo mật mới.
Phê duyệt thay đổi bảo mật trong CDK Pipeline
Trong bài viết này, tôi sẽ hướng dẫn bạn cách thêm một bước phê duyệt thủ công vào AWS Cloud Development Kit (CDK) Pipelines để xác nhận các thay đổi bảo mật trước khi triển khai. Với giải pháp này, khi một nhà phát triển thực hiện một thay đổi, CDK pipeline sẽ xác định một sự thay đổi quyền IAM, tạm dừng quá trình thực thi và gửi thông báo cho một kỹ sư bảo mật để phê duyệt hoặc từ chối thay đổi trước khi nó được triển khai.
Giới thiệu
Trong vai trò của tôi, tôi đã nói chuyện với rất nhiều khách hàng thích thú với AWS Cloud Development Kit (CDK). Một trong những điều họ thích là các construct L2 thường tạo ra các chính sách IAM và bảo mật khác. Điều này có thể tiết kiệm rất nhiều thời gian và công sức so với việc viết mã chính sách thủ công. Hầu hết khách hàng cũng cho tôi biết rằng các chính sách được tạo ra bởi CDK thường an toàn hơn so với những chính sách họ tạo ra thủ công.
Tuy nhiên, những khách hàng này cũng lo lắng rằng đội ngũ kỹ sư bảo mật của họ không biết chính sách CDK tạo ra có gì. Trong quá khứ, những khách hàng này đã dành rất nhiều thời gian để tạo ra một số ít chính sách IAM mà các nhà phát triển có thể sử dụng trong ứng dụng của họ. Những chính sách này được hiểu rõ, nhưng quá cho phép do thường được sử dụng lại trong nhiều ứng dụng khác nhau.
Khách hàng muốn có thêm khả năng xem xét các chính sách mà CDK tạo ra. May mắn thay, CDK cung cấp một cơ chế để phê duyệt các thay đổi bảo mật. Nếu bạn đang sử dụng CDK, bạn có thể đã nhận được lời mời phê duyệt các thay đổi bảo mật khi bạn chạy cdk deploy tại dòng lệnh. Điều này hoạt động tốt trên máy của một nhà phát triển, nhưng khách hàng muốn tích hợp cùng xác nhận này vào luồng triển khai liên tục của họ. CDK cung cấp một cơ chế cho điều này với hành động ConfirmPermissionsBroadening. Lưu ý rằng ConfirmPermissionsBroadening chỉ được hỗ trợ bởi máy triển khai AWS CodePipeline.
Lịch sử
Trước khi tôi nói về ConfirmPermissionsBroadening, hãy để tôi xem xét cách CDK tạo chính sách IAM. Hãy xem xét ứng dụng “Hello, CDK” được tạo trong AWS CDK Workshop. Cuối module này, tôi có một hàm AWS Lambda và một Amazon API Gateway được xác định bằng mã CDK sau đây.
// xác định một tài nguyên AWS Lambda
const hello = new lambda.Function(this, ‘HelloHandler’, {
runtime: lambda.Runtime.NODEJS_14_X, // môi trường thực thi
code: lambda.Code.fromAsset(‘lambda’), // mã được tải từ thư mục “lambda”
handler: ‘hello.handler’ // tên file là “hello”, tên hàm là “handler”
});
// xác định một tài nguyên API Gateway REST API được hỗ trợ bởi hàm “hello” của chúng tôi.
new apigw.LambdaRestApi(this, ‘Endpoint’, {
handler: hello
});
Lưu ý rằng tôi không cần phải xác định IAM Role hoặc Quyền Lambda. Tôi chỉ cần truyền một tham chiếu đến hàm Lambda cho API Gateway (dòng 10 ở trên). CDK hiểu tôi đang làm gì và đã tạo ra các quyền cho tôi. Ví dụ, CDK đã tạo ra Quyền Lambda sau đây, bao gồm các quyền khác.
{
“Effect”: “Allow”,
“Principal”: {
“Service”: “apigateway.amazonaws.com”
},
“Action”: “lambda:InvokeFunction”,
“Resource”: “arn:aws:lambda:us-east-1:123456789012:function:HelloHandler2E4FBA4D”,
“Condition”: {
“ArnLike”: {
“AWS:SourceArn”: “arn:aws:execute-api:us-east-1:123456789012:9y6ioaohv0/prod/*/”
}
}
}
Lưu ý rằng CDK đã tạo ra một chính sách với phạm vi hẹp, cho phép một API cụ thể (dòng 10 ở trên) gọi một hàm Lambda cụ thể (dòng 7 ở trên). Chính sách này không thể tái sử dụng ở nơi khác. Sau đó trong cùng workshop, tôi đã tạo một Construct Hit Counter bằng cách sử dụng một hàm Lambda và một bảng Amazon DynamoDB. Một lần nữa, tôi liên kết chúng bằng một dòng mã CDK duy nhất.
table.grantReadWriteData(this.handler);
Như trong ví dụ trước, CDK đã tạo ra một chính sách IAM với phạm vi hẹp. Chính sách này cho phép hàm Lambda thực hiện các hành động cụ thể (dòng 4-11) trên một bảng cụ thể (dòng 14 bên dưới).
{
“Effect”: “Allow”,
“Action”: [
“dynamodb:BatchGetItem”,
“dynamodb:ConditionCheckItem”,
“dynamodb:DescribeTable”,
“dynamodb:GetItem”,
“dynamodb:GetRecords”,
“dynamodb:GetShardIterator”,
“dynamodb:Query”,
“dynamodb:Scan”
],
“Resource”: [
“arn:aws:dynamodb:us-east-1:123456789012:table/HelloHitCounterHits”
]
}
Như bạn có thể thấy, CDK đã thực hiện rất nhiều công việc cho tôi. Hơn nữa, CDK đang tạo ra các chính sách với phạm vi hẹp cho mỗi tài nguyên, thay vì chia sẻ một chính sách với phạm vi rộng trong nhiều vị trí khác nhau.
Kiểm tra Quyền CDK Pipelines
Bây giờ sau khi tôi đã xem xét cách CDK tạo chính sách, hãy thảo luận về cách tôi có thể sử dụng điều này trong một luồng triển khai liên tục. Cụ thể, tôi muốn cho phép CDK tạo chính sách, nhưng tôi muốn một kỹ sư bảo mật xem xét bất kỳ thay đổi nào bằng cách sử dụng bước phê duyệt thủ công trong luồng triển khai. Tất nhiên, tôi không muốn bảo mật trở thành một nút cổ chai, vì vậy tôi chỉ yêu cầu phê duyệt khi các câu lệnh bảo mật hoặc quy tắc lưu lượng được thêm vào. Luồng triển khai sẽ bỏ qua bước phê duyệt thủ công nếu không có quy tắc bảo mật mới được thêm vào.
Hãy tiếp tục sử dụng CDK Workshop như một ví dụ. Trong module CDK Pipelines, tôi đã sử dụng CDK để cấu hình AWS CodePipeline để triển khai ứng dụng “Hello, CDK” mà tôi đã thảo luận ở trên. Một trong những việc cuối cùng tôi thực hiện trong workshop là thêm một bài kiểm tra xác nhận bằng cách sử dụng bước sau triển khai. Thêm một kiểm tra quyền tương tự, nhưng tôi sẽ sử dụng một bước trước triển khai để đảm bảo kiểm tra quyền xảy ra trước khi triển khai.
Đầu tiên, tôi sẽ nhập ConfirmPermissionsBroadening từ gói pipelines
import {ConfirmPermissionsBroadening} from “aws-cdk-lib/pipelines”;
Sau đó, tôi có thể dễ dàng thêm ConfirmPermissionsBroadening vào deploySatage bằng cách sử dụng phương thức addPre như sau.
const deploy = new WorkshopPipelineStage(this, ‘Deploy’);
const deployStage = pipeline.addStage(deploy);
deployStage.addPre(
new ConfirmPermissionsBroadening(“PermissionCheck”, {
stage: deploy
})
deployStage.addPost(
// Đoạn mã kiểm tra sau triển khai bị bỏ qua
)
Sau khi tôi commit và push thay đổi này, một bước phê duyệt thủ công mới có tên PermissionCheck.Confirm sẽ được thêm vào giai đoạn Deploy của luồng triển khai. Trong tương lai, nếu tôi push một thay đổi thêm quy tắc bảo mật, luồng triển khai sẽ tạm dừng ở đây và chờ phê duyệt thủ công như được hiển thị trong ảnh chụp màn hình dưới đây.
Hình 1. Luồng triển khai chờ xem xét thủ công
Khi kỹ sư bảo mật nhấp vào nút xem xét, cô ấy sẽ thấy hộp thoại sau. Từ đây, cô ấy có thể nhấp vào URL để xem tóm tắt các thay đổi tôi yêu cầu, được ghi lại trong nhật ký xây dựng. Cô ấy cũng có thể chọn phê duyệt hoặc từ chối thay đổi và thêm ý kiến nếu cần.
Hình 2. Hộp thoại xem xét thủ công với liên kết đến nhật ký xây dựng
Khi kỹ sư bảo mật nhấp vào URL xem xét, cô ấy sẽ thấy tóm tắt về các thay đổi bảo mật như sau.
Hình 3. Tóm tắt các thay đổi bảo mật trong nhật ký xây dựng
Tính năng cuối cùng tôi muốn thêm là thông báo qua email để kỹ sư bảo mật biết khi cần phê duyệt. Để thực hiện điều này, tôi tạo một chủ đề Amazon Simple Notification Service (SNS) mới và đăng ký nó và gán với ConfirmPermissionsBroadening Check.
// Tạo chủ đề SNS và đăng ký cho phê duyệt bảo mật
const topic = new sns.Topic(this, ‘SecurityApproval’);
topic.addSubscription(new subscriptions.EmailSubscription(‘security-approvers@example.com’));
deployStage.addPre(
new ConfirmPermissionsBroadening(“PermissionCheck”, {
stage: deploy,
notificationTopic: topic
})
Với thông báo được cấu hình, kỹ sư bảo mật sẽ nhận được một email khi cần phê duyệt. Cô ấy sẽ có cơ hội xem xét các thay đổi bảo mật tôi đã thực hiện và đánh giá tác động của chúng. Điều này mang lại cho đội ngũ kỹ thuật bảo mật khả năng theo dõi họ muốn vào các chính sách mà CDK tạo ra. Ngoài ra, bước phê duyệt được bỏ qua nếu một thay đổi không thêm quy tắc bảo mật, vì vậy kỹ sư bảo mật không trở thành một điểm nút cổ chai trong quá trình triển khai.
Kết luận
AWS Cloud Development Kit (CDK) tự động tạo ra các chính sách IAM và các chính sách bảo mật khác. Điều này có thể tiết kiệm rất nhiều thời gian và công sức, nhưng đội ngũ kỹ thuật bảo mật muốn xem xét các chính sách mà CDK tạo ra. Để giải quyết điều này, CDK Pipelines cung cấp hành động ConfirmPermissionsBroadening. Khi bạn thêm ConfirmPermissionsBroadening vào luồng CI/CD của bạn, CDK sẽ đợi phê duyệt thủ công trước khi triển khai một thay đổi bao gồm các quy tắc bảo mật mới.
AWS Study Group 