传统安全模型依赖边界防火墙，默认内部网络是可信的。但现实中大量攻击事件证明，一旦攻击者突破边界拿到一台主机的权限，就能在内部网络中横行无阻。微隔离（Microsegmentation）正是针对这个问题提出的方案：它把安全控制粒度从网络级别下沉到工作负载级别，每台主机、每个进程、每个容器都可以拥有独立的访问策略。Fedora系统在实现微隔离方面有天然优势，firewalld、SELinux、nftables这些组件开箱即用，本文就来详细讲解如何在Fedora上落地一套微隔离策略。
微隔离的核心思想与传统防火墙的区别
理解微隔离，关键是抓住“粒度”和“默认拒绝”这两个词。传统防火墙的策略通常长这样：允许内网网段访问数据库服务器的3306端口。这条规则覆盖的是整个内网，任何一台内网机器都能尝试连接数据库。而微隔离的策略则是：只允许标签为web-tier的工作负载访问标签为db-tier的3306端口，其他一律拒绝。粒度从IP段变成了逻辑身份，策略跟工作负载走，而不是跟网络拓扑走。
两者另一个重要区别在于东西向流量的管控能力。传统防火墙擅长管南北向流量，也就是外部进内部、内部出外部的流量。但对于同一内网中服务器之间的互相访问，往往缺乏管控手段。微隔离的重点恰恰是东西向流量，它假设攻击者已经在内网中，目标是限制其横向移动的能力。比如一台Web服务器被拿下后，攻击者想用它去扫描和访问数据库、消息队列，微隔离策略会直接阻断这些非授权访问。
在Fedora上实现微隔离，实际是多个组件协同的过程。网络层面靠firewalld和nftables控制端口与源目标；进程与文件层面靠SELinux限制进程能访问的资源；容器场景则依赖namespace、cgroup加上SELinux的联合管控。下面逐一展开。
用firewalld构建网络层隔离策略
firewalld是Fedora默认的防火墙管理工具，它的zone（区域）机制非常适合做初步的微隔离。每个zone代表一套信任等级和规则集合，网卡可以绑定到不同zone，从而让不同网段的流量接受不同策略。先查看当前的zone配置：
# 查看当前激活的zone firewall-cmd --get-active-zones # 查看所有可用的zone firewall-cmd --get-zones # 查看某个zone的完整配置 firewall-cmd --zone=internal --list-all
一个典型的做法是，把对外提供服务的网卡放在external或public zone，把内部管理流量所在的网卡放在trusted或internal zone。假设一台Fedora主机上有两块网卡，ens3面对业务网络，ens4面对管理网络，可以这样配置：
# 把ens4绑定到internal zone firewall-cmd --zone=internal --change-interface=ens4 --permanent # 业务网卡只放行特定端口，且限定来源地址 firewall-cmd --zone=public --add-interface=ens3 --permanent firewall-cmd --zone=public --add-rich-rule='rule family="ipv4" source address="10.20.0.0/24" port port="8443" protocol="tcp" accept' --permanent # 内部zone只允许管理网段访问SSH firewall-cmd --zone=internal --add-rich-rule='rule family="ipv4" source address="10.30.0.0/24" port port="22" protocol="tcp" accept' --permanent firewall-cmd --reload
rich rule是firewalld中实现精细化控制的关键能力，它允许同时指定来源地址、目标端口、协议甚至日志动作。注意上面第二条规则，8443端口并不是对全网开放，而是只允许10.20.0.0/24这个业务网段访问。这就是微隔离思想在网络层的直接体现：不是开放服务，而是为特定来源开放服务。
不过firewalld的能力边界也要清楚。它本质上管理的是主机自身的出入站流量，如果需要更复杂的条件匹配，比如按连接状态、按时间、按包标记做策略，就需要下探到nftables层面。firewalld的后端本身就是nftables，可以查看生成的原生规则来加深理解：
# 查看firewalld生成的nftables规则集 nft list ruleset | head -50
用SELinux实现进程级微隔离
网络层隔离只能控制“谁能连到哪个端口”，但无法控制“进程拿到连接后能做什么”。假设攻击者通过Web服务的漏洞拿到了httpd进程的权限，如果没有SELinux，这个进程可以读取home目录、写定时任务、尝试提权。SELinux通过强制访问控制（MAC）给每个进程打上安全上下文标签，策略引擎会判定进程标签是否有权访问目标资源标签，这与微隔离的“身份化策略”理念完全一致。
确认SELinux处于Enforcing模式：
# 查看当前模式 getenforce # 临时切换模式（重启失效） setenforce 1 # 永久修改为Enforcing # 编辑/etc/selinux/config，设置 SELINUX=enforcing
查看进程和文件的安全上下文：
# 查看进程上下文 ps -eZ | grep httpd # 查看文件上下文 ls -Z /var/www/html/ # 修改文件上下文并恢复 semanage fcontext -a -t httpd_sys_content_t "/srv/web(/.*)?" restorecon -Rv /srv/web
这里的核心概念是type enforcement：httpd_t类型的进程默认只能访问httpd_sys_content_t类型的文件、只能绑定http_port_t类型的端口。如果你把站点数据放到非标准目录而不修正上下文，服务就会拒绝访问，这不是故障，而是隔离策略在生效。排查这类问题用以下命令：
# 查看策略拒绝记录 ausearch -m AVC -ts recent # 生成策略模块建议 audit2why < /var/log/audit/audit.log audit2allow -a -M mywebpolicy semodule -i mywebpolicy.pp
需要提醒的是，使用audit2allow生成策略要谨慎审查每一条规则，盲目放行等于架空隔离。正确的思路是优先调整文件标签或端口标签，把权限收紧到刚好够用，只有策略本身缺少覆盖时才考虑自定义模块。
容器场景下的微隔离实践
Fedora上的容器运行时（Podman或Docker）默认利用namespace做网络隔离，但默认策略往往不够严格。配合SELinux可以进一步收紧：给容器打上sVirt标签后，每个容器进程的SELinux标签都不同（基于 MCS 类别对），容器之间即使root权限相同也无法互相访问文件。这正是微隔离在多租户场景下的典型应用。
# 用Podman运行容器，启用SELinux隔离 podman run -d --name webapp \ -v /srv/web:/var/www/html:Z \ -p 8443:8443 \ quay.io/fedora/httpd-24-base # 查看容器进程的安全标签，注意s0:c后面的类别对是随机分配的 podman top webapp label
上面挂载参数中的大写Z是关键，它会让Podman自动为该卷打上容器私有的SELinux标签，实现容器与宿主机、容器与容器之间的文件隔离。如果多个容器需要共享一个卷，则使用小写z，但要意识到这会放宽隔离边界，需要评估风险。
网络层面，建议为不同业务创建独立的容器网络，而不是让所有容器挤在默认bridge里。配合firewalld限制容器对外暴露的端口与来源，就能形成网络加进程双重隔离。同时养成习惯，容器一律以非root用户运行，加上--user参数指定UID，把攻击面再压缩一层。
策略验证与日常运维建议
微隔离策略写完不等于结束，必须验证它真的生效。最直接的验证方法是从非授权来源尝试访问服务，确认被拒绝并留下日志。可以把firewalld规则配上log动作，把被拒绝的连接记录下来分析：
# 对被拒绝的流量记录日志 firewall-cmd --zone=public --add-rich-rule='rule family="ipv4" source address="10.99.0.0/24" log prefix="MICROSEG-DROP: " level="warning" drop' --permanent firewall-cmd --reload # 观察日志 journalctl -f | grep MICROSEG-DROP
运维层面有三条经验值得遵循。第一，所有策略变更走配置管理工具（如Ansible）而非手工敲命令，保证策略可审计、可回滚；第二，先以permissive思路观察一段时间，收集审计日志确认没有误伤再切换强制模式，尤其对SELinux而言，setroubleshoot-server包配合sealert命令能给出人类可读的冲突解释；第三，定期用nft list ruleset和semanage导出当前生效的策略做基线对比，及时发现配置漂移。
微隔离不是一款软件，而是一套由网络策略、强制访问控制、容器隔离共同组成的纵深防御体系。在Fedora上，firewalld负责网络边界的细粒度放行，SELinux负责进程与资源的身份化管控，容器运行时负责工作负载之间的相互隔离，三者结合就能把“默认信任内网”的旧模型改造成“处处验证、最小授权”的新模型。从小范围试点开始，逐步收紧策略，这套方法在中小规模环境下完全可行。