应用场景
Multi-Factor Authentication (MFA)是一种简单有效的最佳安全实践方法,它能够在用户名和密码之外再额外增加一层安全保护。当一个主账号下拥有多个子账号时,为了检测主账号下的每个子账户是否开启MFA功能,需要每天或自定义时间去做定时检测,并将未开启MFA功能的用户发送给指定的钉钉用户。
解决方案
事件分解:
- 设置定时器。
- 获取主账号下所有子账号。
- 检测每个用户是否开启MFA功能并及返回未开启MFA功能的子账号。
- 将未开启MFA功能的子账号集中发送到指定的钉钉用户。
1.打开控制台,找到运维编排
2.创建模版
根据以上的事件分解,可以为此方案创建为以下两个模版
模版一:
用于单独检测每个子账号的MFA的功能是否处于开启状态,自定义命名模版或者将此模版命名为:CheckMFAUserInfo
FormatVersion: OOS-2019-06-01
Outputs:
User:
Type: String
Value: '{{ userName }}'
Parameters:
userName:
Description: The User Name.
Type: String
OOSAssumeRole:
Description: The RAM role to be assumed by OOS.
Type: String
Default: OOSServiceRole
RamRole: '{{ OOSAssumeRole }}'
Tasks:
- Action: 'ACS::CheckFor'
Name: GetNoMFAUser
Description: 'checking has not MFA Device '
Properties:
Service: RAM
API: GetUserMFAInfo
Parameters:
UserName: '{{ userName }}'
DesiredValues:
- EntityNotExist.User.MFADevice
PropertySelector: .Code
模版二:
获取主账号下的所有子账号,并将每个子账号传给【模版一】来做MFA功能(开/关)状态的检测,将所有未开启MFA功能的用户做聚合处理,统一发送给指定的钉钉用户。自定义命名模版或将此模版命名为:SendMFAUserInfo。注意:当自定义命名【模版一】的名称时,需要将【模版一】的模版名称输入到【模版二】Tasks下的CheckUserMFA的TemplateName里面。
FormatVersion: OOS-2019-06-01
Outputs:
Parameters:
Token:
Description: DingTalk webhook to token.
Type: String
Expression:
Description: Daily task execution time,for example:0 0 2 ? * *
Type: String
EndDate:
Description: The task execution end date,for example:2019-08-02T08:06:49Z or 2019-08-02
Type: String
OOSAssumeRole:
Description: The RAM role to be assumed by OOS.
Type: String
Default: OOSServiceRole
RamRole: '{{ OOSAssumeRole }}'
Tasks:
- Name: DailyMFACheck
Action: 'ACS::TimerTrigger'
Description: Timer for executing task.
Properties:
Type: cron
Expression: '{{ Expression }}'
EndDate: '{{ EndDate }}'
- Action: 'ACS::ExecuteAPI'
Description: All users in the account
Name: listUser
Outputs:
userName:
Type: List
ValueSelector: '.Users.User[].UserName'
Properties:
API: ListUsers
Parameters: Null
Service: RAM
- Name: CheckUserMFA
Action: 'ACS::Template'
Description: Check if the user has an MFA Device.
Properties:
TemplateName: 'CheckMFAUserInfo'
Parameters:
userName: '{{ACS::TaskLoopItem}}'
Outputs:
userName:
Type: String
ValueSelector: User
Loop:
Items: '{{ listUser.userName }}'
MaxErrors: 100
Concurrency: 10
Outputs:
User:
AggregateField: userName
AggregateType: 'Fn::ListJoin'
- Name: DingTalkNotify
Action: 'ACS::Notify'
Description: Send notification to DingTalk via webhook. Please refer https://open-doc.dingtalk.com/microapp/serverapi2/qf2nxq
for details.
Properties:
NotifyType: WebHook
WebHook:
URI: 'https://oapi.dingtalk.com/robot/send?access_token={{ Token }}'
Headers:
Content-Type: application/json
Content:
msgtype: text
text:
content: 'These user has not MFA Device, UserName:{{ CheckUserMFA.User }}'
3.模版创建成功之后就可以创建执行了,此时仅需要执行模版二。
4.模版传参,及点击下一步:确认创建。
参数介绍:
token:检测MFA功能(开/关)状态的信息报告所需接收用户的token。
expression:设置的定期执行时间,此处的设置参数方式如下所示(必须为UTC格式时间,参考云助手的设置定时执行命令,UTC时间在平常的基础上 -8h):
0 15 2 ? 每天上午10:15执行任务
0 0 2,6,8 ? 每天上午10:00点、下午14:00以及下午16:00执行任务
0 0/5 6 ? 每天下午14:00到下午14:55时间段内每隔5分钟执行任务
0 0/30 1-9 ? 每天上午09:00到下午17:00时间段内每隔半小时执行任务
0 10,44 4 ? 3 WED 每年3月的每个星期三下午14:10到14:44时间段内执行任务
0 15 2 ? * 6L 2002-2005 2002年至2005年每月最后一个星期五上午10:15执行任务
endDate:设置执行结束时间(必须为UTC格式的时间:2019-08-02T08:06:49Z or 2019-08-02)
5.点击创建执行
执行开始后,根据设置的expression来周期性的定时执行任务,以及endDate来结束任务。由于定时的周期执行,执行中的状态以及在endDate结束前,子任务如下所示:
6.任务执行成功后发送给钉钉用户的消息显示如下所示:
7.在endDate结束之前,依然会有下一个定时执行。此时执行状态回到等待中,直到时间到达下一次定时此任务会根据定时继续执行。当到实际时间到达endDate时此执行结束。
总结
由以上举例可见,通过嵌套模版的方式去实现了周期性的定时的去执行检测用户的MFA功能的(开/关)状态,并发送钉钉通知,方便按自己需要来设置周期性的执行时间、结束时间及功能检测的目标。目前运维编排(OOS)处于内测中,欢迎试用提意见。
系列文章
主题文章
最佳实践
玩转运维编排服务的权限:Assume Role+Pass Role
场景系列
运维编排场景系列----更新ECS镜像
运维编排场景系列-----给ECS实例自动打TAG
运维编排场景系列----从实例中拷贝文件到OSS
运维编排场景系列----给实例加到SLS机器组
运维编排场景系列----检测MFA功能状态
阿里云运维编排新功能:一键批量克隆ECS