云中网络架构和传统网络架构的区别
在传统网络中，企业内部的网络之间是彼此信任的。但在云中，资源的访问和控制方式发生了质变。在访问一个云端资源的时候，首先需要认证和授权。而其中的核心组件就是Azure Active Directory。
Azure AD
Azure Subscription必须和一个Azure AD关联并由Azure AD为其提供认证服务（反之，一个Azure AD可以和多个Azure Subscription关联）。
Azure AD的认证服务可以支持不同场景，比如：
- 远程工作的员工
- 对企业内部员工和资源提供认证
- SaaS
几种类型的Azure Tenant
User用户账号：可以是公司内部的账号，通常通过用户名/密码方式访问。这种账号可以是云原生账号，从企业内部AD同步过来的账号，也可以是Guest账号。
APP（Service Principal）：代表的是在当前tenant中的一个应用，通常通过secret token或certificate进行认证。这种APP可以在Azure中运行，也可以在其他环境中运行。
Managed Identity：代表一个在Azure Subscription中的服务，只支持在Azure中运行的服务。
Azure中组成员类型
- 静态(assigned): 由相应的管理员赋予，因此管理成本相对较高
- 动态(dynamic): 根据设备/用户属性动态赋予，因此可由平台自动管理。但需要Azure AD Premium P1授权
Azure hybrid identity
- 云原生账号
- 企业内部账号：通过Azure AD Connect同步
- Legacy资源：通过Azure AD DS来进行管理
- Azure AD tenant (domain.onmicrosoft.com) Guest account（通过Azure B2B)
Azure AD Connect
主要是用于支持单点登录，具体包括
- 同步身份
- 身份认证管理
Azure AD Domain Services (ADDS)
如果想要使用传统的Domain Service，例如LDAP。很明显，Azure AD并不直接支持这些legacy domain service。这时就可以通过Azure AD DS作为其中的桥梁。
作为Legacy resource和Azure AD之间的桥梁，Azure ADDS managed domain能够提供添加域，群组策略，LDAP，Kerberos/NTLM认证等服务。
Azure AD Business-to-Business (B2B)
主要应用场景：当自己企业的合作伙伴由自己的用户认证系统时，我们并不能直接信任他们让他们直接访问我们的Azure资源，但可以邀请他们创建我们Azure AD中的Guest账号。这样他们仍然通过自己的认证系统认证，但认证后会关联到我们Azure AD中的Guest账号，进而能访问相应Azure资源。
Azure AD Business-to-Consumer (B2C)
需要创建一个专门的Azure B2C tenant用户（b2cdomain.onmicrosoft.com）自己管理identity
微软正在将Azure AD B2B和Azure AD B2C合并为Azure AD External Identities.
Azure RBAC
主要组成部分：
- Security Principal: 可以是Managed Identity，Security Group, User Account等
- Role definition: 例如Owner, Contributor, VM Contributor等
- Scope：可以是Management Group, Subscription, Resource Group, Resource等
System Managed Identity vs User Managed Identity:
- System Managed Identity: 由Azure自动创建和管理，同时绑定到具体的Azure资源。
- User Managed Identity：非自动创建，但可以在多个Azure资源之间共享。
注意这些权限都是动态计算得到的，比如在指定的scope中添加了一个VM，则具有VM Contributor的用户就自动具有对新添VM的Contributor权限。
Azure AD roles
内置角色：
- Global Admin
- User Admin
- App Admin
- …
就权限而言：
Contributor = Owner - Rights to change permissions
Custom Roles
当内置role的权限不能和需求匹配时，比如不满足least privilege要求时，可以使用custom roles。
在自定义role的时候，无法设置为deny。默认下就是deny，除非明确说明是allow。
Administrative Unit
通过AU，可以把不同的scope进行组合，以便赋予相应权限。
Azure AD Identity Protection
和身份认证相关的风险：
- 81%的数据泄露源自于密码/密钥的泄露
- 73%的密码都是重复的
- 50%的雇员会使用未经企业认证的应用
要想使用Azure AD Identity Protection，需要Azure AD Premium P2授权。
Sign-In Risk Policy: 这是real time policy，当用户登录时就会进行检测。同时还包括了对应的policy何时会被触发以及相应的动作(actions)。
User Risk Policy: 可以在离线时发生。
Azure AD conditional access
- 可以根据不同应用场景来配置不同的规则
- 其触发条件的选择也很多，比如用户位置/IP，设备，浏览器，风险级别等
- 通过conditional access，我们可以设定相应的条件，只有用户满足条件时才能获得访问权限
例如：仅允许Head Office或公共网络+MFA访问Azure资源
Privileged Idnetity Protection
- 在为用户授权之前，可以强制用户完成相应的任务
- 可以审计跟踪用户权限的使用
- 简化同时自动化检查用户是否仍需相应的权限
PIM相当于在用户和Privileges之间又添加了一层控制：
- 相应权限只是非授予，但只有在需要使用时才被激活
- 权限可以在指定的时间后背自动禁用
- 用户对应权限在被激活之前需要相应的批准(approve)才可以
- 可以强制相应用户在激活某个角色之前需要MFA
