超详细零信任市场解读

零信任

零信任的特点:

     “信任”等于“权限”,零信任的实质是通过在网络中消除未经验证的隐含信任 构建安全的业务访问环境。“从不信任,始终验证”是零信任的核心思想,权限最小化是基本原则,在不可信 网络中构建安全系统是零信任的终极目标。

    不再以一个清晰的边界,来划分信任或不信任的设备。(强调无边界);

    不再有信任或不信任的网络(不分内外网);

    不再有信任或不信任的用户(一次认证、静态认证或只靠认证是不可靠的);

    不做任何假定,不信任任何人愿,随时检查一切,防范动态威胁,准备最坏的情况。 

驱动因素:

      国家新基建的推动下云、大、物、移快速发展,千人千面的业务需求下,海量的人、设备、应用接入了互联网,用户类型、设备种类、应用端点越 来越多。设备管理难度增加,访问关系变得极度复杂,各种身份的人、各种类型的设备、应用程序在不同环境 下错综复杂的糅合在了一起。 

     云计算颠覆了传统的边界防御架构。互联网技术发展使基于数据中心、云服务的数据共享成为企业战略新 的业务范式,开放的应用和数据部署在本地及多云计算中心的虚拟机上,不再全部运行在企业自己的硬件设施 上。用户访问云计算中心开放的 IaaS,PaaS 或 SaaS 服务,业务数据从云延伸到端,使得边界难以划分,边 界防御实施越来越难。因此每一个应用和数据的安全访问成为了企业关注的重点。 

    传统的分区分域、ACL策略、子网划分等方式无法提供有效隔离。对多个应用部署在同一物理机上的情况,黑客利用某个应用的 WEB 或数据库漏洞向系统植入恶意代码, 会影响系统内其他业务的安全运行,原来虚拟机还能做到操作系统隔离,现在容器被广泛应用后又爆出很多容器逃逸漏洞,但从业务访问安全角度开看企业势必需要更细粒度的隔离手段。

    基于位置进行内网访问不再可信。 众所周知的棱镜门事件,2018 年的特斯拉生产系 统机密数据泄露事件,2020 年的 Twitter 账号劫持事件,都有效说明“最坚固的堡垒总是从内部攻破的”,访问位置不能说明访问可信。 

    外部严峻的网络威胁态势。随着业务数据含金量提高,黑客不再满足低效的网络层的流量劫持和 DDOS 攻击,转而采用效力和隐蔽性更强,针对特定对象、长期、有计划、有组织的定向攻击方式。2018 年以来全 球 APT 攻击持续高发,勒索事件高居不下,大量的 APT 攻击利用电子邮件进入员工主机投毒、安装恶意代码、 注入木马,通过反连、控制、加密等手段使该主机失陷。其攻击能力已超越了传统网络安全的防御能力,黑客 可以很容易绕过网络访问策略进一步攻击应用程序基础结构。 

发展过程:

    零信任的理念源于美国国防信息系统局 (DISA) 和国防部的一个称为“黑核”(BCORE) 的企业安全战略, 其目标是从边界安全转移向单个事务的安全。 

    国内的零信任发展历程:

    2018 年 9 月,在第六届互联网安全大会(原中国互联网安全大会),中国安全厂家首次提出“安全从 0 开始” 的主题,其第一层含义是“零信任”架构; 

    2019 年 7 月,《零信任安全技术 - 参考框架》作为行业标准在 CCSA TC8 立项;
    2019 年 8 月,《Zero Trust Networks》一书,首次由奇安信身份安全实验室翻译为中文,在国内引进出版; 2019 年 9 月,工信部公开发布指导意见《关于促进网络安全产业发展的指导意见(征求意见稿)》中,将“零 信任安全”列入需要“着力突破的网络安全关键技术”;
    2019 年 9 月,中国信通院发布《中国网络安全产业白皮书 (2019 年 )》中,首次将零信任安全技术和 5G、 云安全等并列列为我国网络安全重点细分领域技术;
    2020 年 6 月 , 在中国产业互联网发展联盟标准专委会指导下,成立了“零信任产业标准工作组”,并于 8 月正式对外发布国内首个基于攻防实践总结的零信任安全白皮书——《零信任实战白皮书》;
    2020 年 8 月,中国信通院联合奇安信集团,在网络安全新技术和应用发展系列发布了《零信任技术》报告; 2020 年 8 月,由奇安信牵头的《信息安全技术零信任参考体系架构》作为国家标准在WG4 立项,成为首个零信任安全国家标准; 

    2020 年 9 月,由腾讯主导的“服务访问过程持续保护参考框架”国际标准成功立项,成为国际上首个零 信任安全技术标准。 

国际厂商:

     根据最新的《Zero Trust eXtended Ecosystem Platform Providers》报告,国际处于领导者地位的零信任 安全厂商以美国居多,主要有:Akamai、Appgate、Cisco、PaloAlto Networks、Illumio、MobileIron。 

        CyberArk,是以色列一家特权管理软件厂家,2019 年 5 月收购身份安全的初创厂家 Idaptive,致力于打 造以身份为中心的零信任的解决方案。 

        Citrix,是一家虚拟化技术为主远程接入解决方案的供应商, 2018 年以来其产品 VPN、虚拟化桌面陆续 暴露出严重漏洞。2020 年该公司加入了 Google BeyondCorp 联盟,在 Citrix Workspace 交付的应用程序中嵌 入 BeyondCorp 的访问控制和执行策略,旨在为其代理的应用提供零信任访问。 

        Cisco,是传统网络设备供应商,零信任产品为 Duo Beyond,Tetration,SD-Access。 

        Akamai 是全球最早最大的 CDN 服务提供商,零信任能力的代表产品有 ETP,EAA 。

        ...

国内厂商:

     * 奇安信和深信服为代表的网络安全厂商,零信任理念核心是以身份认证为基础、安全访问控制为目标,结 合既有安全组件和能力的优势,构造了各具优势特性的零信任安全解决方案。如,奇安信的特点在于“持续信 任评估和动态访问控制”,而深信服的特点是“智能权限、极简运维”。 

    * 新华三和中兴通迅作为传统的综合通信设备厂商,利用通信设备在 5G、云计算、运营商、工业互联等领 域生态建设的优势拓展新的领域,开启零信任安全架构在不同场景下的落地实践。 

    * 竹云科技为代表的身份管理和访问控制厂商,利用全面身份化、融合认证、特权管理的优势能力,打造了 细粒度持续验证鉴权的零信任访问控制解决方案。 

    * 数篷科技为代表的安全技术创新公司,则以虚拟化和云计算相关技术为着力点构建了计算环境隔离为主的 零信任解决方案。 

 

零信任的三种实现方式:(三者互补,IAM是零信任架构的支撑,其余两者关注南北和东西流量)

1.基于SDP(软件定义边界)的ZTA实现——深信服、奇安信、华三——南北向流量

    SDP 架构包括 SDP 主机和控制器两部分 。技术特点:采用控制面和数据面分离的模型,基于身份验证授权主体

访问的资产范围。SDP 将应用与不 安全的网络隔离开来,为应用程序所有者提供了边界的防护能力。在网络被访问之前,每个企业资产都会隐藏 在远程访问网关设备后,用户必须向该设备提供身份验证的授权凭证,才能看到授权服务并提供访问。

    此类厂商一般是传统的安全厂商出身,有丰富的的远程接入产品或身份权限产品的经验,如深信服、奇安信、新华三。深信服内部也将零信任产品线定位为替换VPN的远程接入方案,与传统VPN边界的实现原理不同,SDP零信任是靠会话代理的方式,在客户端发起请求后,由于DNS的NS记录被改动,企业的泛域名解析权限被指到零信任网关上,客户端与零信任网关建立连接,网关进行识别判断他是否做过认证,做过即代理,没做过即与控制器连接进行认证,认证过后,整个会话由网关代理在用户权限内与真实业务建立独立应用会话连接,奇安信、华三还能提供api代理,所以SDP在访问控制粒度上能做到单包授权(SPA)策略,会话过程会持续检测终端状态,如从请求报文中获取五元组、浏览器版本、操作系统版本等信息、或者通过客户端监控终端上的进程状态、或者访问时间、地理位置、访问频次,奇安信还可以做到识别主体的操作习惯,所有的终端状态一旦发生了状态变化,即认为不可信,需重新认证。也被称为持续信任评估。

双向TLS(mTLS)

    通常传统VPN设备使用的TLS为单向认证,即只有一个对象校验对端的证书合法性。通常都是client来校验服务器的合法 性。这样方案中对于访问的端侧设备是无法验证的,也就是会明显存在非法客户端访问的情况,无法保 证终端设备针对服务器端的可信 。因此,在SDP协议中明确提出需要使用双向认证,即相互校验,服务器需要校验每个client,client也 需要校验服务器。通过双向TLS可以保证在通信开始前,端侧和服务侧的相关合法可信性认证。

 

 

单包授权(SPA)

    SPA是一种轻量级安全协议,在允许访问控制器或网关等相关系统组件所在的网络之前先检查设备或用户身份, 包括请求方的IP地址等在内的连接请求的信息,在单一的网络消息中被加密和认证。SPA的目的是允许服务被防火墙隐藏起来并被默认丢弃,从任何其他主机发送到过来的第一个数据包必须是SPA ,如果接收到任何其他数据包, 则将其视为攻击。所以该防火墙系统应该丢弃所有TCP和UDP数据包,不回复那些连接尝试, 从而不为潜在的攻击者提供任何关于该端口是否正被监听的信息。在认证和授权后,用户被允许访问该服 务。SPA对于SDP不可或缺,用于在客户端和控制器、网关和控制器、客户端和网关等之间的连接中通信。 SDP的目标之一是克服TCP/IP开放和不安全的基本特性。TCP/IP的这个特性允许“先连接后认证”, 使用SDP架构的应用被隐藏在SDP网关/AH后面,从而只有被授权的用户才能访问。另外,SDP组件自身,如控制器和网关也被SPA保护。这允许它们被安全地面向互联网部署,解决传统VPN部署在互联网反倒容易成为第一个攻击对象的尴尬境地,确保合法用户可以高效可靠地访问,而未授权用户则看不到这些服务。 

   目前SPA实现的方法不算理想,奇安信、联软默认关闭网关的443端口,仅开放一个UDP 端口,客户端每次访问都会发送SPA敲门包,敲门包连接UDP端口后,看到SPA才能给对方打开443端口进行认证,此做法在实际项目中遇到一个漏洞,即经过SNAT的IP敲门后,同一网络的其他IP均可信。而深信服是通过在TLS协议中加入SPA字段,基于每一个会话包做SPA的认证。但两者均存在一个问题,零信任的理念是不区分内外网等传统可信边界,但在SPA分发这步业内厂商还是选择了信任一方,即认为从内网邮箱等来源获得的exe文件是安全的。

SPA可为用户提供以下安全效果:

   1)服务隐藏:防火墙的Default-drop(默认丢弃)规则缓解了端口扫描和相关侦查技术带来的威胁。 这种防火墙使得SPA组件对未授权用户不可见,显著减小了整个SDP的攻击面。相比与VPN的 开放端口以及在很多实现中都存在的已知弱点,SPA更安全。

   2)缓解DDOS攻击:如果一个HTTPS服务暴露在公共互联网而能被攻击,很少的流量就可能使其死机。 SPA使服务只对认证的用户可见,因而所有DDoS攻击都默认由防火墙丢弃而不是由被保 护的服务自己处理。

   3)0day保护:当一个漏洞被发现时,只有被认证的用户才能够访问受影响的服务,使该 漏洞的破坏性显著减小 。 

   风险点:SDP 类似一个柔性的访问控制网关,访问一旦被授权,请求主体与被访问资源间建立直接链接, 访问流量进入企业内网,随之也会给内网带来一定风险。 因此,应用中需要考虑终端的访问是否安全及是否在安全的环境下发起访问连接。 针对此问题深信服的做法是在零信任客户端融入了终端准入的部分功能,在设备入网之前对设备自身的运行状态如操作系统、补丁、是否运行杀毒软件甚至某特定程序进行审核,以达到进入企业内网的安全门槛,所以成熟的SDP方案会集成NAC。

SDP如何保障云业务的安全性

1.基础设施即服务 (IaaS) 

IaaS平台的安全性是围绕行业标准的“共享责任”模型构建的, 其中云提供商承担一定的责任(云自身的安全性),而客户负责 保护其应用程序(云上的安全性)。IaaS中客户使用云网络安全组控制对其云资源的访问。这些网络安全组作为简单的防火墙配置和使用。这些安全措施可以与软件定义边界SDP集成,创建一 个更加健壮的安全环境。

 

2.平台即服务 (PaaS) 

与标准硬件或基于IaaS的系统相比,PaaS产品允许企业以更小成本构建和部署定制应用程序。与IaaS和SaaS不同,对PaaS系统的 网络访问控制(以及SDP的相关程度)取决于PaaS提供者提供的功能以及启用外部访问控制的方式。 

3.软件即服务 (SaaS) 

SaaS应用程序是多租户的,并可以在公共互联网上公 开访问。目前,防止未经授权的用户进行网络级访问 并不是这些系统的目标。组织机构可能希望在采用 SaaS 应用程序时加强安全性,原因如下: 

* 确保只有授权设备上的授权用户才能访问该特定组织租用 的SaaS 

* 确保SaaS应用程序使用管理的企业IAM身份凭证进行身份认 证 

* 确保用户访问SaaS应用程序时强制进行多因子身份认证 确保对SaaS应用程序访问的所有行为都被识别并记录 

 

2.基于IAM(身份管理与访问控制)的ZTA实现——代表厂商竹云科技——身份安全

   IAM的主要目标是确保正确的人或“物”出于正确的原因,能够在正确的时间、正确的地点从正确的设备中获取到正确的资源(应用、数据等)。 

   身份安全技术大概发展的几个阶段:

 1)  SS0:即单点登录,解决的是用户体验,无特定类别用户,无访问控制能力。

 2) 4A:认证Authentication、授权Authorization、账号Account、审计Audit,中文名称为统一安全管理平台解决方案。即将身份认证、授权、记账和审计定义为网络安全的四大组成部分,从而确立了身份认证在整个网络安全系统中的地位与作用。4A的特点是关注内部员工,关注人员生命周期管理 ,关注权限统一管理,关注 用户身份变化和访问信息记录后可以事后审计 ,安全厂商在传统4A基础上各有延伸,如深信服IDTrust产品,本质与4A相同,但提供自服务、联动堡垒机等运维设备、联动用户现有认证体系等功能。

 3) IAM:

        1.身份管理

面向对象:2E、2C、2B、2IOT,实现全生命周期管理 。

        身份管理实体内容包括组织、应用、设备、权限、凭证、账户等。身份管理客体实现Service All In的单点,将B\S,C\S不同类别应用、移动应用、云端应用、API、数据、设备,不同浏览器访问等统一纳管 。
         2.认证

        实现MFA(3个what),MFA(Multi Factor Authentication)为多因子认 证,通过将“拥有因素”、“知识因素”、“内在 因素”进行组合,形成比单一因子认证更加安全的 认证组合方式。只有当两种及其以上不同因子的认 证方式通过后,才能获取计算机资源。 除口令认证、生物认证、证书认证等常见认证形式,还提供社交认证(需预集成)、设备认证(PUF-物理不可克隆函数 ,当输入一个激励时, PUF电路利用芯片生产过程 中难以预测和克隆的工艺偏差,产生一个响应,一般称为 激励响应对(CRP) ,由于工艺偏差的客观因素,CRP一般难以预测和克隆。)、联邦认证(联邦身份认证,指不同身份源之间的 使用 认证互信,即在一个认证源完成认证 联邦 后,通过联邦机制,其他认证源同样 身份 认可之前的认证,并完成登录等操作 ,类似单点登录)

       3.访问控制

         细粒度授权(应用系统的按钮级别授权 ),应用访问授权,无授权,核心权限授权。

       4.审计风控

          身份管理分析:是否有重复账号、违建账号、僵尸账号、用户账号状态..

          安全监控与预警:账号非正常IP登陆、非正常时间、爆破、异地登陆..

          访问行为分析:UEBA、用户登陆/登出数量、活跃用户排行、应用访问量排行..

           威胁情报分析:风险IP、黑产手机号、慢性攻击分析、密码撞库..

           运维管理分析:数据同步监控预警、身份认证监控预警、接口异常预警..

            

 

3.基于微隔离(MSG)的ZTA实现——东西向流量

    东西向流量指由数据中心内部服务器彼此相互访问所造成的内部流量,据统计,当代数据中心 75%以上的流量为东西向流量。 东西向常见的风向包括数据泄漏、病毒传播、内鬼等。但传统安全建设思路存在一经授权,随意访问的漏洞,一旦边界的防线被攻破或绕过,攻击者就可以在数据中心内部横向移动,而中心内部基本没有安全控制的手段可以阻止攻击。 

     从16年开始微隔离连续三年被Gartner评为全球十大安全项目/技术之一 ,在云安全纬度上还包括cwpp、容器安全等安全项目。微隔离概念也被安全厂商应用到了终端安全edr产品上,把网络安全边界下降至虚拟网卡,致力于边界防护失效时提供主机之间的细粒度隔离,提供流量可视,配合行为分析引擎、病毒查杀引擎实时监测业务之间的一且流量状况并进行授权内的自动隔离。

    微隔离之前常见的东西向流量控制方案在云环境下存在的问题——

     VLAN、ACL:

    1)静态的安全域划分限 定了虚拟机的位置, 与云数据中心的动态特性相悖 ;

    2)虚拟机数量大幅增 加,过大的vlan/子网 划分会给攻击者提供 较大的攻击范围,一 旦vlan中一台主机被 控制,攻击者就可以 随意的横向移动。 

    3)细分安全域,然后部署数百甚至数千个 防火墙以做到内部访问控制,在成本和操作上是不可行的。 

    4)在新增业务或改变现有 业务时,安全人员必须 手动修改安全策略,从 而符合这个静态又重量 级的网络拓扑,大幅增 加业务延迟,也容易造 

成配置错误。 

    5)VLAN/子网、防火墙的配 置错误、策略更改均是 网络中断的常见原因。 尤其是防火墙的策略配 置,无法预先测试、错 误配置很难排查,防火 墙策略往往存在“只敢 增,不敢减”的问题。  

   6)网络规模越大,此模式的网络性能损耗越大。

    安全资源池引流:目前几个安全厂商都有云安全资源池的方案,相当于把安全设备软件化交付,或者有虚拟化能力的厂商如深信服提供软硬件一体交付,在数据中心中利用SDN技术或在核心交换进行流量牵引,流量通过安全资源池的访问控制、检测、清洗后,再发送至目的地。 在实际的云场景应用中遇到如下问题:

    1)    延迟大大增加,比如同一台物理机上的两个虚拟机,互相访问也需要引出去,增加了网络的复杂度。 

    2)增加了单点故障,内部流量比南北向大的多,一旦出现问题,内部就会中断 。

    3)网络需要进行SDN改造,涉及交换设备的更改。  

    4)核心交换流量牵引无法控制、识别不经过其的流量。
    安全池的主要价值在于流量的审计与检测,并不适用于实时性要求较高的东西向隔离。 

    云原生的微隔离与传统网络隔离的区别:基于业务设计策略,基于业务管理策略,提升策略的稳定性, 安全设计与网络设计分离,网络变化不影响策略执行。 海量的节点,频繁的变化,都不适宜通过人工来做网络安全配 置,否则必将大大降低云的敏捷性,增加策略错误; 微隔离在云环境下的边界体现在策略随行,传统隔离设备通过acl做ip、端口、协议的隔离,但云环境下可能随时发生虚拟机漂移、复制、克隆、扩展,导致业务的IP地址等静态参数变化,传统的网络隔离设备就会失效,节点量大的情况下重新靠人工更新策略任务量巨大,用户陷入要么降低安全需求,要不降低业务节奏的两难困境,微隔离策略随行就能做到策略跟随业务动态变化,增强云上隔离的便捷性。这种路线在虚拟化平台提供者中比较常见。往往在虚拟化平台、IaaS、hypervisor或基础设施中提供。例如华为 云,阿里云,Vmware NSX,AWS等,不过一般只支持自身的虚拟化平台,不支持混合云。

    除云原生微隔离外微隔离还有其他的技术路线,技术的组件可以是传统的网络隔离设备,如第三方防火墙(由专业的安全厂商提供的虚拟化防火墙,缺点是需要与平台做对接,成本高,存在性能损耗问题)、网关设备,也可以是安全容器、 安全沙箱等虚拟化技术。作用都可以实现应用程序间的防护,区别在于技术实现方式不同,前者是采用虚拟化和访问控制技术,将应用与周边的访问流量旁路到虚拟化安全组件,从而监管应用间的横向数据流动,与应用程序独立部署。安全容器和沙箱采用微分段和虚拟化融合的内生安全技术,在计算环境层面上使操作系统或应 用从宿主机中分离出来,使受保护应用和数据在一个相对独立且受控的系统内运行,多以虚拟机或容器的方式 部署。根据形态不同,该安全组件可以是单个组件也可以是网关和 agent 组合的多个组件。前提是需要有一个 基于身份治理的系统对这些组件进行管理、配置和策略下发。因此,微分段的设备多应用在策略执行点上。 

    优势在于:适用范围广,能在网络、终端、服务器上部署,实现不同安全域、服务间的隔离,用户可根据 资源的划分由粗到细逐步细化。 

    风险可能会存在于:黑客通过非隔离系统渗透后启动恶意软件对物理内存等硬件组件进行旁路攻击是导致 隔离系统数据泄露和被盗的风险之一。 

 

零信任的适用场景:

1.云计算环境的安全访问

     云计算赋能企业创新,业务云化迁移成为企业重要的商业战略,企业业务不再部署在自己拥有的服务器上, 资产的风险和暴露面逐渐变大。首先,云计算环境下基础资源共享,不同商家的业务在共享的虚拟化系统上部 署,但底层就可能与不安全的应用部署在同一台物理服务器上,恶意代码很容易通过横向移动进入相邻的业务 系统中。其次,业务在云端共享后访问主体的类别变得复杂,根据《2020 年云安全报告》的调查,未经授权 的云访问成为云平台的 4 大威胁之一。不同身份的访问用户,商家不同角色的管理者,云平台的配置人员,系 统间开放的 API 都需要独立的访问权限,权限划分需要更加细致和安全。 

    零信任能很好帮助企业构建云业务的安全交付网络,是云计算的原生安全解决方案。 

    如下图所示,在云服务环境下,用户访问请求不会直接连接到云业务的目标服务器,而是在云数据中心边 界,采用 CDN 网络构建的分发节点代理目标服务器与请求用户建立连接,由云端访问控制器对访问请求进行 验证、最小化授权,保证访问用户只能看到授权范围的服务页面,最后由缓存服务器响应用户的访问请求。 

    在 CDN 分发网络中,最小访问权限原则能保证每一个访问权限范围与其角色匹配,减少资源过度开放, 减少攻击面,减少交叉配置错误导致服务异常。 

    在云数据中心,应用部署时利用虚拟化和微隔离技术,保证应用在一个相对安全的计算环境中运行,阻止 不同应用之间的数据流动,避免恶意代码在东西向横向渗透。 

 

2.远程移动办公:安全团队通常尝试通过VPN,NAC和VLAN的组合 控制远程访问权限,这种解决方案通常是孤岛式的,不保护本地用户,访问控制规则粒度粗,不符合最小权限原则。SDP替换VPN也是醉基本的场景。

3.特权访问

4.防御DDOS

零信任技术演进和未来期望:

    数字业务转型是个全球性话题,边云协同发展是必然趋势,零信任已将安全延伸到端,必将成为未来端边 管云融合 / 协同应用中端到端连接的新安全赛道。   

    1.会替代传统的用户身份的访问控制

    2.会与传统的安全防护并存

    3.零信任与未来 SASE 会很好融合。 

  • 2
    点赞
  • 20
    收藏
    觉得还不错? 一键收藏
  • 2
    评论
好的,我会为你详细解读如何自定义 Node-RED 节点的示例。 首先,你需要准备一个 Node.js 环境和 Node-RED。然后,我们来看看如何创建一个简单的自定义节点。 1. 创建一个新的文件夹,命名为 "node-red-contrib-myfirstnode",并在其中创建一个名为 "myfirstnode.js" 的文件,这个文件将包含我们的自定义节点的代码。 2. 在 Node-RED 的安装目录下找到 "nodes" 文件夹,并将 "node-red-contrib-myfirstnode" 文件夹复制到该文件夹中。 3. 打开 "myfirstnode.js" 文件,开始编写自定义节点的代码。以下是一个简单的示例: ```javascript module.exports = function(RED) { function MyFirstNode(config) { RED.nodes.createNode(this,config); var node = this; node.on('input', function(msg) { //处理节点输入 node.send(msg); //将处理后的结果传递给下一个节点 }); } RED.nodes.registerType("myfirstnode",MyFirstNode); } ``` 4. 在代码中,我们使用 `module.exports` 导出我们的自定义节点函数。该函数接受一个参数 `RED`,它是一个全局变量,它允许我们访问 Node-RED 的 API。 5. 在函数中,我们定义了一个名为 `MyFirstNode` 的构造函数。这个构造函数接受一个参数 `config`,它是我们在 Node-RED 编辑器中配置节点时提供的配置数据。 6. 在构造函数中,我们使用 `RED.nodes.createNode` 方法来创建一个新的节点实例。我们还将 `this` 和 `config` 传递给此方法,这将设置节点的 `id` 和 `name` 属性,并将配置数据存储在 `config` 属性中。 7. 接下来,我们定义了一个名为 `node` 的变量,并在 `this` 上调用 `on` 方法来监听输入事件。当节点接收到输入消息时,我们可以在回调函数中处理它,并使用 `node.send` 方法将处理后的消息传递给下一个节点。 8. 最后,我们使用 `RED.nodes.registerType` 方法来注册我们的自定义节点类型。这个方法需要两个参数:节点类型的名称和我们定义的构造函数。在这个例子中,我们将节点类型命名为 "myfirstnode",并将构造函数传递给 `registerType` 方法。 9. 现在,我们可以启动 Node-RED 并在编辑器中找到我们的自定义节点。我们可以将它拖放到流程中,并配置它的参数,然后测试它是否按预期工作。 希望这个解读能够帮助你理解如何自定义 Node-RED 节点,并让你开始构建自己的节点。如果你有任何疑问,请随时问我。

“相关推荐”对你有帮助么?

  • 非常没帮助
  • 没帮助
  • 一般
  • 有帮助
  • 非常有帮助
提交
评论 2
添加红包

请填写红包祝福语或标题

红包个数最小为10个

红包金额最低5元

当前余额3.43前往充值 >
需支付:10.00
成就一亿技术人!
领取后你会自动成为博主和红包主的粉丝 规则
hope_wisdom
发出的红包
实付
使用余额支付
点击重新获取
扫码支付
钱包余额 0

抵扣说明:

1.余额是钱包充值的虚拟货币,按照1:1的比例进行支付金额的抵扣。
2.余额无法直接购买下载,可以购买VIP、付费专栏及课程。

余额充值