Arch - 架构安全性_验证（Verification）

文章目录

OverView
导图
1. 引言：数据验证的重要性概述
2. 数据验证的基本概念
3. 数据验证的层次
- 前端验证
- 后端验证
4. 数据验证的标准做法
5. 自定义校验注解
6. 校验结果的处理
7. 性能考虑与副作用
8. 小结

OverView

即使只限定在“软件架构设计”这个语境下，系统安全仍然是一个很大的话题。

接下来我们将对系统安全架构的各个方面进行详细分析，包括认证、授权、凭证、保密、传输安全和验证，结合案例实践，展示如何应用这些安全原则和技术，讨论具体解决方案和行业标准，并提供与业界标准相一致的解决方案。

计划：

认证（Authentication）：
- 介绍认证的基本概念及其在软件架构中的作用。
- 讨论常见的认证方法（如用户名/密码、双因素认证、生物识别）及其实现方式。
- 探讨行业标准和最佳实践（如 OAuth、OpenID Connect）。
授权（Authorization）：
- 定义授权的概念及其重要性。
- 讲解不同的授权模型（如基于角色的访问控制RBAC、基于属性的访问控制ABAC）。
- 介绍如何在架构中实现这些模型以及如何处理权限管理。
凭证（Credential）：
- 阐明凭证的作用及其管理方式。
- 讨论如何确保证书和凭证的真实性、完整性和不可抵赖性。
- 介绍现有的凭证管理方案和技术（如 PKI、公钥基础设施）。
保密（Confidentiality）：
- 解释数据保密的基本概念及其在系统中的应用。
- 讨论数据加密的技术和策略（如对称加密、非对称加密）。
- 介绍如何确保保密性，包括数据存储和处理中的加密措施。
传输（Transport Security）：
- 定义传输安全及其对系统安全的影响。
- 讲解如何实现传输层安全（如 TLS/SSL）的具体方法。
- 讨论如何保护网络通信免受中间人攻击和数据篡改。
验证（Verification）：
- 介绍数据验证的必要性及其对系统稳定性的影响。
- 讨论常见的验证技术（如输入验证、数据完整性检查）。
- 讲解如何在系统中实现数据验证机制以保证数据一致性和正确性。

导图

在这里插入图片描述

专家：软件开发 > 数据验证专家
要求：对数据验证的全面分析，包括最佳实践、常见问题和解决方案，重点讨论 Java 中的 Bean Validation

计划：

引言：数据验证的重要性
数据验证的基本概念
数据验证的层次
- 前端验证
- 后端验证
数据验证的标准做法
- Java Bean Validation
自定义校验注解
校验结果的处理
性能考虑与副作用
总结与未来展望

1. 引言：数据验证的重要性概述

数据验证不仅是确保用户输入正确性的手段，也是维护系统稳定性、数据一致性和安全性的重要措施。

2. 数据验证的基本概念

数据验证是指在数据被处理或存储之前，对其进行检查以确保数据符合预定义的规则。验证可以包括：

格式验证：确保数据符合预期的格式（如邮箱、电话号码）。
业务规则验证：确保数据符合特定的业务逻辑（如用户唯一性）。

3. 数据验证的层次

前端验证

前端验证通常通过JavaScript进行，能够提供即时反馈，减少无效请求。这种验证可以捕捉一些基本错误，但并不足以替代后端验证。

后端验证

后端验证是确保数据在被处理前进行全面检查的关键。它可以防止不合法的数据通过API提交到服务器，并对业务逻辑进行严格控制。

4. 数据验证的标准做法

在Java中，采用Java Bean Validation（JSR 380）是进行数据验证的标准方法。该规范支持一系列内置的校验注解，如@NotNull、@Email、@Size等。

注解驱动：通过在Bean类的属性上使用注解定义校验规则。
统一管理：所有校验逻辑集中于Bean中，便于管理和维护。

5. 自定义校验注解

当内置注解无法满足业务需求时，可以自定义校验注解。例如，在用户注册中，需要确保用户名的唯一性。

与业务相关的校验往往才是最复杂的校验，将简单的校验交给 Bean Validation，而把复杂的校验留给自己，这简直是买椟还珠故事的程序员版本。其实以 Bean Validation 的标准方式来做业务校验是非常优雅的

/**
* 创建新的用户
*/
@POST
public Response createUser(@Valid @UniqueAccount Account user) {
	return CommonResponse.op(() -> service.createAccount(user));
}

/**
* 更新用户信息
*/
@PUT
@CacheEvict(key = "#user.username")
public Response updateUser(@Valid @AuthenticatedAccount @NotConflictAccount Account user) {
	return CommonResponse.op(() -> service.updateAccount(user));
}

注意其中的三个自定义校验注解，它们的含义分别是：

@UniqueAccount：传入的用户对象必须是唯一的，不与数据库中任何已有用户的名称、手机、邮箱产生重复。
@AuthenticatedAccount：传入的用户对象必须与当前登录的用户一致。
@NotConflictAccount：传入的用户对象中的信息与其他用户是无冲突的，譬如将一个注册用户的邮箱，修改成与另外一个已存在的注册用户一致的值，这便是冲突。

这里的需求很容易理解，注册新用户时，应约束不与任何已有用户的关键信息重复；而修改自己的信息时，只能与自己的信息重复，而且只能修改当前登录用户的信息。这些约束规则不仅仅为这两个方法服务，它们可能会在用户资源中的其他入口被使用到，乃至在其他分层的代码中被使用到，在 Bean 上做校验就能一揽子地覆盖上述这些使用场景。下

下面代码是这三个自定义注解对应校验器的实现类

public static class AuthenticatedAccountValidator extends AccountValidation<AuthenticatedAccount> {
    public void initialize(AuthenticatedAccount constraintAnnotation) {
        predicate = c -> {
            AuthenticAccount loginUser = (AuthenticAccount) SecurityContextHolder.getContext().getAuthentication().getPrincipal();
            return c.getId().equals(loginUser.getId());
        };
    }
}

public static class UniqueAccountValidator extends AccountValidation<UniqueAccount> {
    public void initialize(UniqueAccount constraintAnnotation) {
        predicate = c -> !repository.existsByUsernameOrEmailOrTelephone(c.getUsername(), c.getEmail(), c.getTelephone());
    }
}

public static class NotConflictAccountValidator extends AccountValidation<NotConflictAccount> {
    public void initialize(NotConflictAccount constraintAnnotation) {
        predicate = c -> {
            Collection<Account> collection = repository.findByUsernameOrEmailOrTelephone(c.getUsername(), c.getEmail(), c.getTelephone());
            // 将用户名、邮件、电话改成与现有完全不重复的，或者只与自己重复的，就不算冲突
            return collection.isEmpty() || (collection.size() == 1 && collection.iterator().next().getId().equals(c.getId()));
        };
    }
}

这样业务校验便和业务逻辑就完全分离开来，在需要校验时用@Valid注解自动触发，或者通过代码手动触发执行，可根据你们项目的要求，将这些注解应用于控制器、服务层、持久层等任何层次的代码之中。此外，校验结果不满足时的提示信息，也便于统一处理，如提供默认值、提供国际化支持、提供统一的客户端返回格式（创建一个用于ConstraintViolationException的异常处理器来实现.

对于 Bean 与 Bean 校验器，笔者另外有两条编码建议。第一条是对校验项预置好默认的提示信息，这样当校验不通过时用户能获得明确的修正提示，以下是代码示例：

/**
 * 表示一个用户的信息是无冲突的
 *
 * “无冲突”是指该用户的敏感信息与其他用户不重合，譬如将一个注册用户的邮箱，修改成与另外一个已存在的注册用户一致的值，这便是冲突
 **/
@Documented
@Retention(RUNTIME)
@Target({FIELD, METHOD, PARAMETER, TYPE})
@Constraint(validatedBy = AccountValidation.NotConflictAccountValidator.class)
public @interface NotConflictAccount {
    String message() default "用户名称、邮箱、手机号码与现存用户产生重复";
    Class<?>[] groups() default {};
    Class<? extends Payload>[] payload() default {};
}

另外一条建议是将不带业务含义的格式校验注解放到 Bean 的类定义之上，将带业务逻辑的校验放到 Bean 的类定义的外面。这两者的区别是放在类定义中的注解能够自动运行，而放到类外面则需要像前面代码那样，明确标出注解时才会运行。譬如用户账号实体中的部分代码为：

public class Account extends BaseEntity {
	@NotEmpty(message = "用户不允许为空")
    private String username;

    @NotEmpty(message = "用户姓名不允许为空")
    private String name;

    private String avatar;

    @Pattern(regexp = "1\\d{10}", message = "手机号格式不正确")
    private String telephone;

    @Email(message = "邮箱格式不正确")
    private String email;
}

这些校验注解都直接放在类定义中，每次执行校验的时候它们都会被运行。由于 Bean Validation 是 Java 的标准规范，它执行的频率可能比编写代码的程序所预想的要更高，譬如使用 Hibernate 来做持久化时，便会自动执行 Data Object 上的校验注解。对于那些不带业务含义的注解，运行是不需要其他外部资源参与的，不会调用远程服务、访问数据库，这种校验重复执行并没有什么成本。

但带业务逻辑的校验，通常就需要外部资源参与执行，这不仅仅是多消耗一点时间和运算资源的问题，由于很难保证依赖的每个服务都是幂等的，重复执行校验很可能会带来额外的副作用。因此应该放到外面让使用者自行判断是否要触发。

还有一些“需要触发一部分校验”的非典型情况，譬如“新增”操作 A 需要执行全部校验规则，“修改”操作 B 中希望不校验某个字段，“删除”操作 C 中希望改变某一条校验规则，这时候要就要启用分组校验来处理，设计一套“新增”、“修改”、“删除”这样的标识类，置入到校验注解的groups参数中去实现

6. 校验结果的处理

有效的校验结果处理是提升用户体验的关键。当校验失败时，系统应返回清晰的错误信息，指导用户进行修正。使用统一的异常处理机制可以实现这一点。

@ControllerAdvice
public class ValidationExceptionHandler {
    @ExceptionHandler(ConstraintViolationException.class)
    public ResponseEntity<Object> handleValidationException(ConstraintViolationException ex) {
        // 返回错误信息
    }
}