OceanBase 安全审计之透明加密

这篇具有很好参考价值的文章主要介绍了OceanBase 安全审计之透明加密。希望对大家有所帮助。如果存在错误或未考虑完全的地方,请大家不吝赐教,您也可以点击"举报违法"按钮提交疑问。

承接前文 OceanBase 安全审计的《传输加密》,本文主要实践数据透明加密,并验证加密是否有效。

作者:张乾,外星人2号,兼任四位喵星人的铲屎官。

爱可生开源社区出品,原创内容未经授权不得随意使用,转载请联系小编并注明来源。

本文约 1200 字,预计阅读需要 4 分钟。

环境

版本:OceanBase 4.1.0.0 企业版

加密配置

详细的 加密步骤 略过,本次使用 MySQL 租户。

开启透明加密并创建表空间

管理员用户登录到集群的 MySQL 租户。

# 开启 internal 方式的透明加密
# tde_method 默认值为 none,表示关闭透明表空间加密
obclient [oceanbase]>  ALTER SYSTEM SET tde_method='internal';
Query OK, 0 rows affected (0.022 sec)

obclient [oceanbase]> SHOW PARAMETERS LIKE 'tde_method';
+-------+----------+-------------+----------+------------+-----------+----------+------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------+----------+--------+---------+-------------------+
| zone  | svr_type | svr_ip      | svr_port | name       | data_type | value    | info                                                                                                                                                                                                 | section  | scope  | source  | edit_level        |
+-------+----------+-------------+----------+------------+-----------+----------+------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------+----------+--------+---------+-------------------+
| zone1 | observer | 172.17.0.13 |     2882 | tde_method | NULL      | internal | none : transparent encryption is none, none means cannot use tde, internal : transparent encryption is in the form of internal tables, bkmi : transparent encryption is in the form of external bkmi | OBSERVER | TENANT | DEFAULT | DYNAMIC_EFFECTIVE |
+-------+----------+-------------+----------+------------+-----------+----------+------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------+----------+--------+---------+-------------------+
1 row in set (0.017 sec)

# 执行该语句,生成主密钥
obclient [oceanbase]> ALTER INSTANCE ROTATE INNODB MASTER KEY;
Query OK, 0 rows affected (0.028 sec)

# 创建表空间并指定加密算法,其中 'y' 表示默认使用 aes-256 算法
obclient [oceanbase]> CREATE TABLESPACE sectest_ts1 encryption = 'y';
Query OK, 0 rows affected (0.021 sec)

在加密表空间内创建新表

普通用户登录到数据库的 MySQL 租户,创建新表 t1

# 创建表并指定表空间
obclient [sysbenchdb]> CREATE TABLE t1 (id1 int, id2 int) TABLESPACE sectest_ts1;
Query OK, 0 rows affected (0.076 sec)

# 确认表空间内的表是否标记为加密
# encryptionalg 为 aes-256,且 encrypted 为 YES 则表示表加密配置成功
obclient [oceanbase]> SELECT table_name,encryptionalg,encrypted FROM oceanbase.V$OB_ENCRYPTED_TABLES;
+------------+---------------+-----------+
| table_name | encryptionalg | encrypted |
+------------+---------------+-----------+
| t1         | aes-256       | YES       |
+------------+---------------+-----------+
1 row in set (0.048 sec)

往表内插入一条值,并做大合并,使值落盘 SSTable。

# 插入值
obclient [sysbenchdb]> insert into t1 values (147852369,999999991);
Query OK, 1 row affected (0.005 sec)

# 做大合并
ALTER SYSTEM MAJOR FREEZE TENANT=ALL;

# 查看合并进度
SELECT * FROM oceanbase.CDB_OB_ZONE_MAJOR_COMPACTION\G

创建一个不加密的表用以对比

普通用户登录到数据库的 MySQL 租户,创建不指定加密空间的新表 ttttttt2

同样插入一条数据,并做大合并。

obclient [sysbenchdb]> CREATE TABLE ttttttt2 (id1 int, id2 int);
Query OK, 0 rows affected (0.076 sec)
obclient [sysbenchdb]> insert into ttttttt2 values (147852369,999999991);
Query OK, 1 row affected (0.005 sec)

# 做大合并
ALTER SYSTEM MAJOR FREEZE TENANT=ALL;

# 查看合并进度
SELECT * FROM oceanbase.CDB_OB_ZONE_MAJOR_COMPACTION\G

加密验证

验证方式是借助工具 ob_admin,其 dumpsst 功能可以显示 block_file 文件中的内容。

使用 dumpsst 来查看加密表的内容,验证是否加密。

使用前需要知道目标数据的 macro block id,接下来先找到上面数据对应的 macro block id

查找 macro block id

先根据 oceanbase.DBA_OB_TABLE_LOCATIONS 找到两张表的 TABLET_ID,其中加密表 t1TABLET_ID 为 200001,未加密表 ttttttt2TABLET_ID 为 200002。

obclient [oceanbase]> select * from oceanbase.DBA_OB_TABLE_LOCATIONS where TABLE_NAME='t1';
+---------------+------------+----------+------------+----------------+-------------------+------------+---------------+-----------+-------+-------+-------------+----------+--------+--------------+
| DATABASE_NAME | TABLE_NAME | TABLE_ID | TABLE_TYPE | PARTITION_NAME | SUBPARTITION_NAME | INDEX_NAME | DATA_TABLE_ID | TABLET_ID | LS_ID | ZONE  | SVR_IP      | SVR_PORT | ROLE   | REPLICA_TYPE |
+---------------+------------+----------+------------+----------------+-------------------+------------+---------------+-----------+-------+-------+-------------+----------+--------+--------------+
| sysbenchdb    | t1         |   500006 | USER TABLE | NULL           | NULL              | NULL       |          NULL |    200001 |  1001 | zone1 | 172.17.0.13 |     2882 | LEADER | FULL         |
+---------------+------------+----------+------------+----------------+-------------------+------------+---------------+-----------+-------+-------+-------------+----------+--------+--------------+
1 row in set (0.005 sec)

obclient [oceanbase]> select * from oceanbase.DBA_OB_TABLE_LOCATIONS where TABLE_NAME='ttttttt2';
+---------------+------------+----------+------------+----------------+-------------------+------------+---------------+-----------+-------+-------+-------------+----------+--------+--------------+
| DATABASE_NAME | TABLE_NAME | TABLE_ID | TABLE_TYPE | PARTITION_NAME | SUBPARTITION_NAME | INDEX_NAME | DATA_TABLE_ID | TABLET_ID | LS_ID | ZONE  | SVR_IP      | SVR_PORT | ROLE   | REPLICA_TYPE |
+---------------+------------+----------+------------+----------------+-------------------+------------+---------------+-----------+-------+-------+-------------+----------+--------+--------------+
| sysbenchdb    | ttttttt2   |   500007 | USER TABLE | NULL           | NULL              | NULL       |          NULL |    200002 |  1001 | zone1 | 172.17.0.13 |     2882 | LEADER | FULL         |
+---------------+------------+----------+------------+----------------+-------------------+------------+---------------+-----------+-------+-------+-------------+----------+--------+--------------+
1 row in set (0.005 sec)

拿着 TABLET_ID,根据合并时间,在 GV$OB_TABLET_COMPACTION_HISTORY 中找到 MACRO_ID_LIST,其中记录的 ID 即是我们需要的 macro block id

从输出中,我们可以看到加密表 t1 对应的 macro block id 为 387,未加密表 ttttttt2 对应的 macro block id 为 718。

obclient [oceanbase]> select * from GV$OB_TABLET_COMPACTION_HISTORY where TABLET_ID=200001 and TYPE='MAJOR_MERGE'  order by START_TIME \G
*************************** 1. row ***************************
                              SVR_IP: 172.17.0.13
                            SVR_PORT: 2882
                           TENANT_ID: 1004
                               LS_ID: 1001
                           TABLET_ID: 200001
                                TYPE: MAJOR_MERGE
                      COMPACTION_SCN: 1685093467526445446
                          START_TIME: 2023-05-26 17:31:22.478149
                         FINISH_TIME: 2023-05-26 17:31:22.482045
                             TASK_ID: YB42AC11000D-0005FC95091493EB-0-0
                         OCCUPY_SIZE: 432
                   MACRO_BLOCK_COUNT: 1
       MULTIPLEXED_MACRO_BLOCK_COUNT: 0
        NEW_MICRO_COUNT_IN_NEW_MACRO: 1
MULTIPLEXED_MICRO_COUNT_IN_NEW_MACRO: 0
                     TOTAL_ROW_COUNT: 1
               INCREMENTAL_ROW_COUNT: 1
                   COMPRESSION_RATIO: 0.67
                 NEW_FLUSH_DATA_RATE: 100
        PROGRESSIVE_COMPACTION_ROUND: 1
          PROGRESSIVE_COMPACTION_NUM: 0
                     PARALLEL_DEGREE: 1
                       PARALLEL_INFO: -
                   PARTICIPANT_TABLE: table_cnt=4,[MAJOR]scn=1;[MINI]start_scn=1,end_scn=1685093478867382402;
                       MACRO_ID_LIST: 387
                            COMMENTS: serialize_medium_list:{cnt=1;1685093467526445446}|time_guard=EXECUTE=4.20ms|(0.79)|CREATE_SSTABLE=648us|(0.12)|total=5.32ms;
*************************** 2. row ***************************
                              SVR_IP: 172.17.0.13
                            SVR_PORT: 2882
                           TENANT_ID: 1004
                               LS_ID: 1001
                           TABLET_ID: 200001
                                TYPE: MAJOR_MERGE
                      COMPACTION_SCN: 1685094492266634220
                          START_TIME: 2023-05-26 17:48:27.276906
                         FINISH_TIME: 2023-05-26 17:48:27.282468
                             TASK_ID: YB42AC11000D-0005FC9509149878-0-0
                         OCCUPY_SIZE: 432
                   MACRO_BLOCK_COUNT: 1
       MULTIPLEXED_MACRO_BLOCK_COUNT: 0
        NEW_MICRO_COUNT_IN_NEW_MACRO: 1
MULTIPLEXED_MICRO_COUNT_IN_NEW_MACRO: 0
                     TOTAL_ROW_COUNT: 1
               INCREMENTAL_ROW_COUNT: 1
                   COMPRESSION_RATIO: 0.67
                 NEW_FLUSH_DATA_RATE: 71
        PROGRESSIVE_COMPACTION_ROUND: 1
          PROGRESSIVE_COMPACTION_NUM: 0
                     PARALLEL_DEGREE: 1
                       PARALLEL_INFO: -
                   PARTICIPANT_TABLE: table_cnt=3,[MAJOR]scn=1685093467526445446;[MINI]start_scn=1685093467530410154,end_scn=1685094504683817069;
                       MACRO_ID_LIST: 718
                            COMMENTS: serialize_medium_list:{cnt=1;1685094492266634220}|time_guard=EXECUTE=5.92ms|(0.45)|CREATE_SSTABLE=5.94ms|(0.45)|total=13.10ms;

obclient [oceanbase]> select * from GV$OB_TABLET_COMPACTION_HISTORY where TABLET_ID=200002 and TYPE='MAJOR_MERGE'  order by START_TIME \G
*************************** 1. row ***************************
                              SVR_IP: 172.17.0.13
                            SVR_PORT: 2882
                           TENANT_ID: 1004
                               LS_ID: 1001
                           TABLET_ID: 200002
                                TYPE: MAJOR_MERGE
                      COMPACTION_SCN: 1685094492266634220
                          START_TIME: 2023-05-26 17:48:27.277801
                         FINISH_TIME: 2023-05-26 17:48:27.284542
                             TASK_ID: YB42AC11000D-0005FC9509149879-0-0
                         OCCUPY_SIZE: 424
                   MACRO_BLOCK_COUNT: 1
       MULTIPLEXED_MACRO_BLOCK_COUNT: 0
        NEW_MICRO_COUNT_IN_NEW_MACRO: 1
MULTIPLEXED_MICRO_COUNT_IN_NEW_MACRO: 0
                     TOTAL_ROW_COUNT: 1
               INCREMENTAL_ROW_COUNT: 1
                   COMPRESSION_RATIO: 0.61
                 NEW_FLUSH_DATA_RATE: 40
        PROGRESSIVE_COMPACTION_ROUND: 1
          PROGRESSIVE_COMPACTION_NUM: 0
                     PARALLEL_DEGREE: 1
                       PARALLEL_INFO: -
                   PARTICIPANT_TABLE: table_cnt=4,[MAJOR]scn=1685093467526445446;[MINI]start_scn=1,end_scn=1685094504683817070;
                       MACRO_ID_LIST: 718
                            COMMENTS: serialize_medium_list:{cnt=1;1685094492266634220}|time_guard=EXECUTE=10.20ms|(0.86)|total=11.87ms;

解析 block_file 文件

安装完 ob_admin,使用 dumpsst 解析上个步骤拿到的 macro block id

注意:

  1. ob_admin dumpsst 必须在 ${path_to_oceanbase}/oceanbase 层级运行,原因是读取 etc/observer.config.bin 使用的是相对路径。
  2. 目前测试下来,必须指定 --macro-id,否则都会报错(报错内容需在 ob_admin.log 中查看)。

介绍本次使用的几个参数如下:

  • -f 指定 data 目录。
  • -d 宏块类型,目前仅支持 macro_block。
  • -amacro-id,填写上面步骤中获取的值。
  • -t 指定 tablet_id,进一步精确范围。
  • -imicro block id,-1 表示所有 micro blocks。

解析 t1 表,即加密表

可以看到输出中 tablet_id 为 200001,row_count 为 1,对应我们插入的那一条数据。

其中并未展示这行数据内容,验证数据成功加密。

[admin@ob_4 oceanbase]$ ob_admin dumpsst  -f /home/admin/oceanbase/store/obdemo/  -d macro_block -a 387 -t 200001 -i -1
succ to open, filename=ob_admin.log, fd=3, wf_fd=2
old log_file need close, old = ob_admin.log new = ob_admin.log
succ to open, filename=ob_admin.log, fd=3, wf_fd=2
succ to open, filename=ob_admin_rs.log, fd=4, wf_fd=2
------------------------------{Common Header}------------------------------
|                   header_size|24
|                       version|1
|                         magic|1001
|                          attr|1
|                  payload_size|952
|              payload_checksum|-1027413104
--------------------------------------------------------------------------------
------------------------------{SSTable Macro Block Header}------------------------------
|                   header_size|208
|                       version|1
|                         magic|1007
|                     tablet_id|200001
|               logical_version|1685093467526445446
|                      data_seq|0
|                  column_count|5
|           rowkey_column_count|3
|                row_store_type|1
|                     row_count|1
|                   occupy_size|432
|             micro_block_count|1
|       micro_block_data_offset|232
|                 data_checksum|2617981320
|               compressor_type|6
|                 master_key_id|500004
--------------------------------------------------------------------------------
--------{column_index        column_type    column_order column_checksum  collation_type}----------
|       [0                  ObUInt64Type             ASC      3344869974              63]
|       [1                     ObIntType             ASC       313654433              63]
|       [2                     ObIntType             ASC      2388842353              63]
|       [3                   ObInt32Type             ASC      2776795072              63]
|       [4                   ObInt32Type             ASC        82537422              63]
--------------------------------------------------------------------------------

解析 ttttttt2 表,即未加密的表

替换命令中 tablet_idmacro block idttttttt2 表的 id,进行解析。

对比加密表 t1,未加密表输出信息更丰富,并且可以看到具体的数据内容。

此处精简展示,可以看到 Total Rows 中显示了前面插入的那条数据[{"INT":147852369}][{"INT":999999991}]。

[admin@ob_4 oceanbase]$ ob_admin dumpsst  -f /home/admin/oceanbase/store/obdemo/  -d macro_block -a 718 -t 200002 -i -1
succ to open, filename=ob_admin.log, fd=3, wf_fd=2
old log_file need close, old = ob_admin.log new = ob_admin.log
succ to open, filename=ob_admin.log, fd=3, wf_fd=2
succ to open, filename=ob_admin_rs.log, fd=4, wf_fd=2
------------------------------{Common Header}------------------------------
|                   header_size|24
|                       version|1
|                         magic|1001
|                          attr|1
|                  payload_size|892
|              payload_checksum|-1696352947
--------------------------------------------------------------------------------
------------------------------{SSTable Macro Block Header}------------------------------
|                   header_size|208
|                       version|1
|                         magic|1007
|                     tablet_id|200002
|               logical_version|1685094492266634220
|                      data_seq|0
|                  column_count|5
|           rowkey_column_count|3
|                row_store_type|1
|                     row_count|1
|                   occupy_size|424
|             micro_block_count|1
|       micro_block_data_offset|232
|                 data_checksum|725485397
|               compressor_type|6
|                 master_key_id|0
--------------------------------------------------------------------------------
……
------------------------------{Total Rows[1]}------------------------------
|ROW[0]:trans_id=[{txid:0}],dml_flag=[N|INSERT],mvcc_flag=[]|[{"BIGINT UNSIGNED":1}][{"BIGINT":-1685094482154160502}][{"BIGINT":0}][{"INT":147852369}][{"INT":999999991}]
……
------------------------------{Encoding Column Header[4]}------------------------------
|                          type|0
|                     attribute|0
|                 is fix length|0
|              has extend value|0
|                is bit packing|0
|             is last var field|0
|            extend value index|65542
|             store object type|0
|                        offset|0
|                        length|0
--------------------------------------------------------------------------------
------------------------------{Index Micro Block[0]}------------------------------
------------------------------{Total Rows[1]}------------------------------
|ROW[0]:trans_id=[{txid:0}],dml_flag=[N|INSERT],mvcc_flag=[]|[{"BIGINT UNSIGNED":1}][{"BIGINT":-1685094482154160502}][{"BIGINT":0}][{"VARCHAR":"
                         ", collation:"binary", coercibility:"NUMERIC"}]
|Index Block Row Header|[{version:1, row_store_type:1, compressor_type:6, is_data_index:1, is_data_block:1, is_leaf_block:0, is_major_node:1, is_pre_aggregated:0, is_deleted:0, contain_uncommitted_row:0, is_macro_node:0, has_string_out_row:0, all_lob_in_row:1, macro_id:[-1](ver=0,mode=0,seq=0), block_offset:232, block_size:192, master_key_id:0, encrypt_id:0, encrypt_key:"data_size:16, data:00000000000000000000000000000000", row_count:1, schema_version:1685094464567160, macro_block_count:0, micro_block_count:1}]
------------------------------{Macro Meta Micro Block}------------------------------
------------------------------{Encoding Micro Header}------------------------------
|                   header_size|96
|                       version|2
|                         magic|1005
|                  column_count|4
|           rowkey_column_count|3
|                     row_count|1
|                row_store_type|2
|                row_index_byte|0
|              var_column_count|0
|               row_data_offset|357
|column_chksum[              0]|3344869974
|column_chksum[              1]|1868627082
|column_chksum[              2]|2388842353
|column_chksum[              3]|1583982749
--------------------------------------------------------------------------------
……

小结

本文主要是使用 ob_admin 工具的 dumpsst 功能解析 block_file,验证了 OceanBase 数据透明加密功能。

使用 dumpsst 过程中碰到问题,建议多关注 ob_admin.log,对于排查比较有帮助。

更多技术文章,请访问:https://opensource.actionsky.com/

关于 SQLE

爱可生开源社区的 SQLE 是一款面向数据库使用者和管理者,支持多场景审核,支持标准化上线流程,原生支持 MySQL 审核且数据库类型可扩展的 SQL 审核工具。文章来源地址https://www.toymoban.com/news/detail-712535.html

SQLE 获取

类型 地址
版本库 https://github.com/actiontech/sqle
文档 https://actiontech.github.io/sqle-docs/
发布信息 https://github.com/actiontech/sqle/releases
数据审核插件开发文档 https://actiontech.github.io/sqle-docs/docs/dev-manual/plugins/howtouse

到了这里,关于OceanBase 安全审计之透明加密的文章就介绍完了。如果您还想了解更多内容,请在右上角搜索TOY模板网以前的文章或继续浏览下面的相关文章,希望大家以后多多支持TOY模板网!

本文来自互联网用户投稿,该文观点仅代表作者本人,不代表本站立场。本站仅提供信息存储空间服务,不拥有所有权,不承担相关法律责任。如若转载,请注明出处: 如若内容造成侵权/违法违规/事实不符,请点击违法举报进行投诉反馈,一经查实,立即删除!

领支付宝红包 赞助服务器费用

相关文章

  • MYSQL8安全之审计管理

    审计:记录用户的操作,方便以后查证,但 生产环境 数据库本身 不建议 开启,会影响性能,可以使用 第三方 实现审计。 mysql5.7 企业版 自带审计功能,需要 付费 。 社区版 可以使用 McAfee 提供的开源软件 mysql Audit Pluging 项目地址:https://github.com/trellix-enterprise/mysql-audit 修改

    2024年02月09日
    浏览(30)
  • 让数据无所畏惧!探索Oracle 12c的强大安全功能:数据红action、数据掩码、加密表空间、统一审计等功能|oracle 12c相对oralce 11g的新特性(4)

    oracle 12c引入了许多新的安全功能,如数据红action、数据掩码、加密表空间等,引入了统一审计功能,可以记录和监视对数据库的所有访问和操作,提高了数据的安全性。 功能说明: 这个功能用于在查询结果中对敏感数据进行动态脱敏,以保护数据隐私。例如,假设有一个员

    2024年02月07日
    浏览(34)
  • Casper Labs 与 IBM Consulting 合作,AI透明度、审计能力的新方案

    ​ “全新解决方案,旨在帮助企业更有效地管理训练数据,这些数据由不同的组织通过生成式人工智能系统产生” 企业区块链软件和服务提供商 Casper Labs 与 IBM Consulting 共同宣布,它们将联手推出新的解决方案,以帮助客户在其人工智能系统中,利用区块链获得更大的透明度

    2024年01月21日
    浏览(29)
  • 14、HDFS 透明加密KMS

    1、hadoop3.1.4简单介绍及部署、简单验证 2、HDFS操作 - shell客户端 3、HDFS的使用(读写、上传、下载、遍历、查找文件、整个目录拷贝、只拷贝文件、列出文件夹下文件、删除文件及目录、获取文件及文件夹属性等)-java 4、HDFS-java操作类HDFSUtil及junit测试(HDFS的常见操作以及H

    2024年02月05日
    浏览(18)
  • 从IDC数据库安全报告,看OceanBase安全能力

    欢迎访问 OceanBase 官网获取更多信息:https://www.oceanbase.com/ 作为数据的承载工具,数据库自身安全能力对于数据安全至关重要。数据库软件诞生至今,经过了几十年的发展和演进,已经成为 IT 系统中不可或缺的关键技术。但是随着数据呈海量、高速增长态势,数据类型越来越

    2024年02月08日
    浏览(93)
  • Oracle Non-CDB配置 TDE(透明数据加密) 的过程

    此文档虽然是针对non CDB而写,但是对于CDB的操作过程也是类似的,即在CDB$ROOT中设置完成wallet设置后,在PDB中设置和打开MEK即可。 请确保目录 $ORACLE_SID/admin/$ORACLE_SID 存在,例如此目录为: /u01/app/oracle/admin/noncdb 配置TDE过程: 下面开始加密数据库的users表空间: 加密过程中的监

    2024年02月09日
    浏览(26)
  • OceanBase与MySQL兼容性对比

    OB针对于高并发和大数据更有优势,公司的dba让我们把数据从mysql迁移到OceanBase了,这里记录一下OceanBase的MySQL模式。 OceanBase的MySQL模式兼容MySQL5.7的绝大部分功能和语法,兼容MySQL5.7版本的全量以及8.0版本的部分JSON函数。 OceanBase暂不支持空间数据类型和部分json类型,其他类别的

    2024年01月17日
    浏览(48)
  • 基于DataX迁移MySQL到OceanBase集群

    📢📢📢📣📣📣 哈喽!大家好,我是【IT邦德】,江湖人称jeames007,10余年DBA及大数据工作经验 一位上进心十足的【大数据领域博主】!😜😜😜 中国DBA联盟(ACDU)成员,目前服务于工业互联网 擅长主流Oracle、MySQL、PG、高斯及Greenplum运维开发,备份恢复,安装迁移,性能优

    2024年03月18日
    浏览(34)
  • 安全审计——等级保护日志审计要求的一种解决方案

        在网络安全等级保护中,对日志有着一系列的要求,通常以部署日志审计系统来满足等保的要求,此处我们选择syslog来实现日志的集中收集,统一管理。     在这里我们主要目标是满足安全区域边界、安全管理中心里的下面两条的要求。其中安全管理中心的日志

    2024年02月16日
    浏览(40)
  • 【网络安全】3.1 网络安全审计

    网络安全审计是一种检查和评估网络安全控制措施、策略和程序的有效性的过程。网络安全审计的目标是识别网络中可能存在的安全漏洞,以及制定改进计划以提高网络安全。 网络安全审计有助于保护组织的信息资产,防止数据泄露,保证业务连续性,并满足合规性要求。通

    2024年02月08日
    浏览(28)

觉得文章有用就打赏一下文章作者

支付宝扫一扫打赏

博客赞助

微信扫一扫打赏

请作者喝杯咖啡吧~博客赞助

支付宝扫一扫领取红包,优惠每天领

二维码1

领取红包

二维码2

领红包