精华内容
下载资源
问答
  • 最小特权原则(PoLP)

    2020-11-14 14:47:16
    在信息安全,计算机科学和其他领域,最小特权原则(PoLP)要求在计算环境的特定抽象层中,每个模块(例如进程,用户或程序)必须只能访问对其合法目的必要的信息和资源。 概述 该原理意味着仅向用户帐户或进程授予...

    在信息安全,计算机科学和其他领域,最小特权原则(PoLP)要求在计算环境的特定抽象层中,每个模块(例如进程,用户或程序)必须只能访问对其合法目的必要的信息和资源。

    概述

    该原理意味着仅向用户帐户或进程授予执行其预期功能所必需的那些特权。例如,仅用于创建备份的用户帐户不需要安装软件:因此,它仅具有运行备份和与备份相关的应用程序的权限。其他任何特权(例如安装新软件)均被阻止。该原则也适用于通常使用普通用户帐户工作的个人计算机用户,并且仅在情况绝对需要时才打开受密码保护的超级用户权限。

    最小特权原则被广泛认为是一种增强对数据和功能的保护的重要设计,以防止错误(容错)和恶意行为(计算机安全)。

    该原则的好处包括:

    • 更好的系统稳定性。如果将代码限制在对系统可以进行的更改范围内,则更容易测试其可能的操作以及与其他应用程序的交互。例如,以受限权限运行的应用程序将无权执行可能会使计算机崩溃或对运行在同一系统上的其他应用程序产生不利影响的操作。
    • 更好的系统安全性。如果代码在系统范围内可能执行的操作中受到限制,则无法使用一个应用程序中的漏洞来利用计算机的其余部分。例如,Microsoft指出“以标准用户模式运行可为客户提供更多保护,以防止因“粉碎攻击”和恶意软件(例如根工具包,间谍软件和不可检测的病毒)造成的系统级意外损坏”。
    • 易于部署。通常,应用程序所需的特权越少,则在更大的环境中进行部署就越容易。这通常是由前两个好处引起的,安装设备驱动程序或需要提升的安全特权的应用程序通常在部署过程中涉及其他步骤。例如,在Windows上,无需安装任何设备驱动程序的解决方案就可以直接运行,而必须使用Windows Installer服务单独安装设备驱动程序才能授予驱动程序更高的特权。

    在实践中,存在多个竞争的真正最低特权定义。由于程序复杂性以指数速度增长,这样做的潜在问题的数量,使预测方法不切实际。

    另一个限制是操作环境对单个进程具有特权的控制粒度。在实践中,几乎不可能以所需的精度来控制进程对内存,处理时间,I/O设备地址或模式的访问。

    从历史上看,最小特权的最旧实例可能是login.c的源代码,该代码以超级用户权限开始执行,并且在不再需要它们时立即通过setuid()将其关闭。

    Linux系统的最小特权原则实现

    内核始终以最大权限运行,因为它是操作系统的核心,具有硬件访问特权。操作系统(尤其是多用户操作系统)的主要职责之一是管理硬件的可用性,并要求从运行的进程中访问它。当内核崩溃时,维护状态的机制也会失败。因此,即使有一种方法可以在不进行硬重置的情况下恢复CPU,安全性仍将继续执行,但是由于无法检测到故障,操作系统无法正确响应故障。这是因为内核执行要么停止,要么程序计数器从一个无尽的(通常是非功能性的)循环中的某个位置恢复执行。

    如果崩溃后通过加载和运行特洛伊木马程序恢复执行,那么特洛伊木马程序的作者就可以篡夺所有进程的控制权。最小特权原则会强制代码以最低的特权/权限级别运行。这意味着恢复代码执行的代码(无论是特洛伊木马程序还是仅从意外位置提取代码执行)将无法执行恶意或不良进程。可以在微处理器硬件中实现一种用于实现此目的的方法。例如,在Intel x86架构中,制造商设计了四个(环0到环3)运行的“模式”,这些模式具有不同访问级别,就像国防和情报机构的系统安全许可一样。其中内核工作在0环,拥有最高权限,而应用程序工作在3环,对硬件访问受限。
    在这里插入图片描述
    当然,进程的不同阶段可能需要不同的特权。比如一个进程最开始的有效身份是真实身份,但运行到中间的时候,需要以其他的用户身份读入某些配置文件,然后再进行其他的操作。为了防止其他的用户身份被滥用,我们需要在操作之前,让进程的有效身份变更回来成为真实身份。这样,进程需要在两个身份之间变化。

    存储身份就是真实身份之外的另一个身份。当我们将一个程序文件执行成为进程的时候,该程序文件的拥有者(owner)和拥有组(owner group)可以被存储成为进程的存储身份。在随后进程的运行过程中,进程就将可以选择将真实身份或者存储身份复制到有效身份,以拥有真实身份或者存储身份的权限。并不是所有的程序文件在执行的过程都设置存储身份的。需要这么做的程序文件会在其九位(bit)权限的执行位的x改为s。这时,这一位(bit)叫做set UID bit或者set GID bit

    我们通常使用chmod来修改set-UID bitset-GID bit:

    $chmod 4700 file
    

    我们看到,这里的chmod后面不再只是三位的数字。最前面一位用于处理set-UID bit/set-GID bit,它可以被设置成为4/2/1以及或者上面数字的和。4表示为set UID bit, 2表示为set GID bit,1表示为sticky bit 。必须要先有x位的基础上,才能设置s位。

    展开全文
  • 最小特权原则

    2014-08-03 09:02:00
    之前的项目中的一些事情的做法违背了最小特权原则(亦为最小权限原则),这里记录以下什么是该原则。 原始定义 该原则最早由Jerome Saltzer提出。其最原始的表述为 Every program and every privileged user of the ...

    之前的项目中的一些事情的做法违背了最小特权原则(亦为最小权限原则),这里记录以下什么是该原则。

    原始定义

    该原则最早由Jerome Saltzer提出。其最原始的表述为 Every program and every privileged user of the system should operate using the least amount of privilege necessary to complete the job.
    其中文意思为
    系统的每个程序或者用户应该使用完成工作所需的最小权限工作。

    带来的好处

    • 更好的系统稳定性。 当一段程序被限定了最小权限原则,就可以更加容易地测试可能的行为以及与其他程序的交互。比如,一个被赋予最小特权的程序没有权限让机器设备崩溃,也不会阻碍同一系统上的其他程序运行。
    • 更好的系统安全性。 当代码在系统范围的行动,它可以执行有限的,在一个应用程序中的漏洞不能用来利用机器的其他部分,例如,微软指出:“运行在标准用户模式为客户提供了更多的保护,防止意外造成“粉碎攻击”和恶意软件,比如根工具包,间谍软件和病毒无法检测“系统级的损坏。
    • 更容易的部署。 通常情况下,在一个比较大的环境下,程序需要权限越少就越容易部署。通常表现在以下两点。需要安装设备驱动或者需要提升权限的程序通常需要额外的步骤来完成部署。比如,Windows下,一个不需要设备驱动的解决方案不需要安装即可运行。而需要安装设备驱动的程序,需要使用Windows Installer服务来来装从而提升驱动的权限。

    延伸阅读

    其他

    展开全文
  • 最小特权原则(POLP) 最小特权原则 (Principle of least privilege,POLP) :是一种信息安全概念,即为用户提供执行其工作职责所需的最小权限等级或许可。 最小特权原则被广泛认为是网络安全的最佳实践,也是...

    最小特权原则(POLP)


    最小特权原则 (Principle of least privilege,POLP) :是一种信息安全概念,即为用户提供执行其工作职责所需的最小权限等级或许可。

    最小特权原则被广泛认为是网络安全的最佳实践,也是保护高价值数据和资产的特权访问的基本方式。

    最小特权原则 (POLP) 重要性


    减少网络攻击面: 当今,大多数高级攻击都依赖于利用特权凭证(提权)。通过限制超级用户和管理员权限,最小权限执行有助于减少总体网络攻击面。
    阻止恶意软件的传播: 通过在服务器或者在应用系统上执行最小权限,恶意软件攻击(例如SQL注入攻击)将很难提权来增加访问权限并横向移动破坏其他软件、设备。
    有助于简化合规性和审核 :许多内部政策和法规要求都要求组织对特权帐户实施最小权限原则,以防止对关键业务系统的恶意破坏。最小权限执行可以帮助组织证明对特权活动的完整审核跟踪的合规性。

    在团队中实施最小特权原则 (POLP) 


    • 在所有服务器、业务系统中,审核整个环境以查找特权帐户(例如SSH账号、管理后台账号、跳板机账号);

    • 减少不必要的管理员权限,并确保所有用户和工具执行工作时所需的权限;
    • 定期更改管理员账号密码;
    • 监控管理员账号操作行为,告警通知异常活动。

    AppArmor限制容器对资源访问


    AppArmor(Application Armor) 是一个 Linux 内核安全模块,可用于限制主机操作系统上运行的进程的功能。每个进程都可以拥有自己的安全配置文件。安全配置文件用来允许或禁止特定功能,例如网络访问、文件读/写/执行权限等。

    Linux发行版内置:Ubuntu、Debian

    Apparmor两种工作模式


    • Enforcement(强制模式) :在这种模式下,配置文件里列出的限制条件都会得到执行,并且对于违反这些限制条件的程序会进行日志记录。

    • Complain(投诉模式):在这种模式下,配置文件里的限制条件不会得到执行,Apparmor只是对程序的行为进行记录。一般用于调试。

    AppArmor限制容器对资源访问


    安全策略是基于文件去设置的,配置了配置文件之后还需要去加载一下
    常用命令:
    • apparmor_status:查看AppArmor配置文件的当前状态的
    • apparmor_parser:将AppArmor配置文件加载到内核中
    • apparmor_parser <profile># 加载到内核中
    • apparmor_parser -r <profile># 重新加载配置
    • apparmor_parser -R <profile># 删除配置
    • aa-complain:将AppArmor配置文件设置为投诉模式,需要安装apparmor-utils软件包
    • aa-enforce:将AppArmor配置文件设置为强制模式,需要安装apparmor-utils软件包

    K8s使用AppArmor的先决条件:
    • K8s版本v1.4+,检查是否支持:kubectl describe node |grep AppArmor
    • Linux内核已启用AppArmor,查看 cat /sys/module/apparmor/parameters/enabled
    • 容器运行时需要支持AppArmor,目前Docker已支持
    root@k8s-master:~# kubectl describe node | grep AppAr
      Ready                True    Sat, 03 Jul 2021 12:31:43 +0800   Sat, 05 Jun 2021 23:41:25 +0800   KubeletReady                 kubelet is posting ready status. AppArmor enabled
    
    
    root@k8s-master:~# cat /sys/module/apparmor/parameters/enabled
    Y

     AppArmor 目前处于测试阶段,因此在注解中指定AppArmor策略配置文件。

    示例:
    apiVersion: v1
    kind: Pod
    metadata:
      name: hello-apparmor
      annotations:
        container.apparmor.security.beta.kubernetes.io/<container_name>: localhost/<profile_ref>
    ...
    • <container_name> Pod中容器名称,也就是对哪个容器生效
    • <profile_ref> Pod所在宿主机上策略名,默认目录/etc/apparmor.d,策略名字是想要手动去创建配置文件的

    如果想要pod使用 apparmor,限制对容器的哪些资源操作,就需要去声明一下让容器使用apparmor,否则默认情况下是不具有这种能力的。

    An introduction to AppArmor Profiles


    An apparmor profile defines what resources (like network, system capabilities, or files) on the system can be accessed by the target confined application.

    Here’s an example of a simple AppArmor profile:

    profile k8s-apparmor-example-deny-write flags=(attach_disconnected) {
      file,
      # Deny all file writes.
      deny /** w,
    }

    In this example, the profile grants the application all kinds of access, except write to the entire file system. It contains two rules:

    • file: Allows all kinds of access to the entire file system.
    • deny /** w: Denies any file write under the root / directory. The expression /** translates to any file under the root directory, as well as those under its subdirectories.

     Setting up a Kubernetes cluster so containers can use apparmor profiles is done with the following steps:

    1. Install and enable AppArmor on all of the cluster nodes.
    2. Copy the apparmor profile you want to use to every node, and parse it into either enforce mode or complain mode.
    3. Annotate the container workload with the AppArmor profile name.

    Here is how you would use a profile in a Pod:

    apiVersion: v1
    kind: Pod
    metadata:
      name: hello-apparmor
      annotations:
        # Tell Kubernetes to apply the AppArmor profile "k8s-apparmor-example-deny-write".
        container.apparmor.security.beta.kubernetes.io/hello: localhost/k8s-apparmor-example-deny-write
    spec:
      containers:
      - name: hello
        image: busybox
        command: [ "sh", "-c", "echo 'Hello AppArmor!' && sleep 1h" ]

    In the pod yaml above, the container named hello is using the AppArmor profile named k8s-apparmor-example-deny-write. If the AppArmor profile does not exist, the pod will fail to be created.

    Each profile can be run in either enforce mode, which blocks access to disallowed resources, or complain mode, which only reports violations. After building an AppArmor profile, it is good practice to apply it with the complain mode first and let the workload run for a while. By analyzing the AppArmor log, you can detect and fix any false positive activities. Once you are confident enough, you can turn the profile to enforce mode.

    If the previous profile runs in enforce mode, it will block any file write activities:

    $ kubectl exec hello-apparmor touch /tmp/test
    touch: /tmp/test: Permission denied
    error: error executing remote command: command terminated with non-zero exit code: Error executing in Docker Container:

    This was a simplified example. Now, think of the challenges of implementing AppArmor in production.

    First, you will have to build robust profiles for each of your containers to prevent attacks without blocking daily tasks.

    Then, you will have to manage several profiles across all the nodes in your cluster.

    案例:容器文件系统访问限制


    容器当中跑着我们的应用程序,想要对文件系统最小权限的访问,默认情况下对容器环境下的文件系统有任何的访问权限。如果黑客进入到你的容器当中,可能想方设法的去提取权限。提权到宿主机上面去。最小权限的目的是为了即使黑客进入到容器他的权限也是非常有限的。可能是很多文件都不能访问,很多的工具都不能使用。

    步骤:

    1、将自定义策略配置文件保存到/etc/apparmor.d/
    2、加载配置文件到内核:apparmor_parser <profile>
    3、Pod注解指定策略配置名
    在pod所在节点上将策略给创建,因为不确定pod会被分配在哪些节点,所以所有的节点都需要创建策略文件,可以使用ansible工具去创建。
    #include <tunables/global>
    profile k8s-deny-write flags=(attach_disconnected) {
      include <abstractions/base>
      file, 
      deny /bin/** w, 
      deny /data/www/** w,
    }
    
    
    #include <tunables/global>   导入依赖,是linux的内核模块,遵循c语言的语法,格式固定
    profile k8s-deny-write flags=(attach_disconnected)  策略名字为k8s-deny-write,这个是需要自己写
    include <abstractions/base>   c语言导入的依赖,格式固定
    
    
    注意,如果策略里面什么都不写就是拒绝一切行为,你在策略里面添加的东西相对于白名单,就是放行

    测试,默认策略,里面什么都不写

    root@k8s-master:~# cd /etc/apparmor.d/
    root@k8s-master:/etc/apparmor.d# cat k8s-deny-write 
    #include <tunables/global>
    profile k8s-deny-write flags=(attach_disconnected) {
      #include <abstractions/base>
      #file,  
      #deny /bin/** w, 
      #deny /data/www/** w,
    }
    
    
    #让这个文件生效一下
    root@k8s-master:/etc/apparmor.d# apparmor_parser -r k8s-deny-write 
    
    #显示加载成功
    root@k8s-master:/etc/apparmor.d# apparmor_status | grep k8s
       k8s-deny-write
    container.apparmor.security.beta.kubernetes.io/hello   hello是指定了容器的名称
    
    apiVersion: v1
    kind: Pod
    metadata:
      name: hello-apparmor
      annotations:
        container.apparmor.security.beta.kubernetes.io/hello: localhost/k8s-deny-write
    spec:
      containers:
      - name: hello
        image: busybox
        command: [ "sh", "-c", "echo 'Hello AppArmor!' && sleep 1h" ]
    
    
    使用默认的策略创建后的pod,进入里面会发现使用touch会提示没有权限,在使用默认策略的时候都是拒绝的行为,这个就相对于白名单,往里面加什么就是要放行什么
    root@k8s-master:/etc/apparmor.d# cat k8s-deny-write 
    #include <tunables/global>
    profile k8s-deny-write flags=(attach_disconnected) {
      #include <abstractions/base>
      file,    #允许所有文件读写,创建和查看文件都有
      deny /bin/** w, #控制某个目录进行读写,这边一般都放可执行的程序
    }
    
    这里都是先放行所有的文件,然后针对具体的目录去限制
    
    修改之后不需要重启容器,只需要使用-r生效一下即可

    工作流程


    当去写pod的yaml的时候,要去注解里面去指定你要使用的AppArmor的容器名称和策略名称,pod会被调度到某个节点上面,这个节点就会去读取AppArmor的配置文件,然后对pod当中容器应用上。

    展开全文
  • 谈将最小特权原则应用到WindowsXP上的用户帐户.doc
  • 更多企业学院 中小企业管理全能版 183套讲座+89700份资料 总经理高层管理 49套讲座+16388份资料 中层管理学院 46套讲座+6020份资料? 国学智慧易经 46套讲座 人力资源学院 56套讲座+27123份资料 各阶段员工培训学院 ...
  • 简介: 最小特权原则是系统安全中最基本的原则之一,它限制了使用者对系统及数据进行存取所需要的最小权限,既保证了用户能够完成所操作的任务,同时也确保非法用户或异常操作所造成的损失最小。本文从安全操作系统...
    朱涛江 ( quepy@sohu.com), 装备指挥技术学院研究生

     

    简介: 最小特权原则是系统安全中最基本的原则之一,它限制了使用者对系统及数据进行存取所需要的最小权限,既保证了用户能够完成所操作的任务,同时也确保非法用户或异常操作所造成的损失最小。本文从安全操作系统及Internet安全的角度来阐述了最小特权原则的应用。

     

    前言

    系统安全的根本目标是数据资料的安全,而数据资料是由它的使用者进行存取和维护的。传统的数据存取和维护,都是以新的数据覆盖旧的数据,对于数据的无心错误,或有心的更改数据,一个管理者并无法有效地查出蛛丝马迹。因此,对数据的存取控制是系统安全的一个重要方面。为此,Sandhu等学者提出了一套以角色为基础的存取控制(Role-based Access Control,RBAC)理论,其基本组件包括使用者(User)、角色(Role)、授权(Authorization)及会话(Session)。如何为每个使用者分配相应的权力(即授权)将是本文将要分析的一个重要原则--最小特权原则(Least Privilege Theorem)。

    最小特权原则简介

    最小特权原则是系统安全中最基本的原则之一。所谓最小特权(Least Privilege),指的是"在完成某种操作时所赋予网络中每个主体(用户或进程)必不可少的特权"。最小特权原则,则是指"应限定网络中每个主体所必须的最小特权,确保可能的事故、错误、网络部件的篡改等原因造成的损失最小"。

    最小特权原则一方面给予主体"必不可少"的特权,这就保证了所有的主体都能在所赋予的特权之下完成所需要完成的任务或操作;另一方面,它只给予主体"必不可少"的特权,这就限制了每个主体所能进行的操作。

    最小特权原则要求每个用户和程序在操作时应当使用尽可能少的特权,而角色允许主体以参与某特定工作所需要的最小特权去签入(Sign)系统。被授权拥有强力角色(Powerful Roles)的主体,不需要动辄运用到其所有的特权,只有在那些特权有实际需求时,主体才去运用它们。如此一来,将可减少由于不注意的错误或是侵入者假装合法主体所造成的损坏发生,限制了事故、错误或攻击带来的危害。它还减少了特权程序之间潜在的相互作用,从而使对特权无意的、没必要的或不适当的使用不太可能发生。这种想法还可以引申到程序内部:只有程序中需要那些特权的最小部分才拥有特权。

    最小特权原则的应用

    安全操作系统

    操作系统对于系统安全来说好比是大楼的地基,如果没有了它,大楼就无从谈起。在计算机系统的各个层次上,硬件、操作系统、网络软件、数据库管理系统软件以及应用软件,各自在计算机安全中都肩负着重要的职责。在软件的范畴中,操作系统处在最底层,是所有其他软件的基础,它在解决安全上也起着基础性、关键性的作用,没有操作系统的安全支持,计算机软件系统的安全就缺乏了根基。对安全操作系统的研究首先从1967年的Adept-50项目开始,随后安全操作系统的发展经历了奠基时期、食谱时期、多政策时期以及动态政策时期。国内对安全操作系统的开发大多处于食谱时期,即以美国国防部的 TCSEC(又称橙皮书)或我国的计算机信息系统安全保护等级划分准则为标准进行的开发。

    最小特权在安全操作系统中占据了非常重要的地位,它适应UNIX操作系统、超级用户/根目录体系结构的固有特征,以便了解如何到达根目录的的任何用户提供总体系统控制——而且几乎在UNIX环境工作的所有程序员都了解这一点。

    角色管理机制依据"最小特权"原则对系统管理员的特权进行了分化,每个用户只能拥有刚够完成工作的最小权限。然后根据系统管理任务设立角色,依据角色划分权限,每个角色各负其责,权限各自分立,一个管理角色不拥有另一个管理角色的特权。例如当入侵者取得系统管理员权限后欲访问一个高安全级别的文件,则很有可能被拒绝。因为用户(包括系统管理员)在登录后默认的安全级别是最低的,他无法访问高级别的文件,而安全级别的调整只有通过安全管理员才能完成。因此,安全管理员只要对敏感文件配置了合理的安全标记,系统管理员就无法访问这些文件。由此可知,安全管理员对系统管理员的权限进行了有力的限制。

    Windows NT操作系统的某些漏洞也与最小特权的应用有关,例如:缺省组的权利和能力总是不能被删除,它们包括:Administrator组,服务器操作员组,打印操作员组,帐户操作员组。这是因为当删除一个缺省组时,表面上,系统已经接受了删除。然而,当再检查时,这些组并没有被真正删除。有时,当服务器重新启动时,这些缺省组被赋予回缺省的权利和能力。为了减小因此而带来的风险,系统管理员可以创建自己定制的组,根据最小特权的原则,定制这些组的权利和能力,以迎合业务的需要。可能的话,创建一个新的Administrator组,使其具有特别的指定的权利和能力。

    下面介绍目前几种安全操作系统及最小特权的应用:

    1. 惠普的Praesidium/Virtual Vault
    2. 它通过以最小特权机制将根功能分成42种独立的特权,仅赋予每一应用程序正常运行所需的最小特权。因而,即便一名黑客将Trojan Horse(特洛伊木马)程序安装在金融机构的Web服务器上,入侵者也无法改变网络配置或安装文件系统。最小特权是在惠普可信赖操作系统Virtual Vault的基本特性。
    3. 红旗安全操作系统(RFSOS)
    4. RFSOS在系统管理员的权限、访问控制、病毒防护方面具有突出的特点,例如在系统特权分化方面,红旗安全操作系统根据"最小特权"原则,对系统管理员的特权进行了分化,根据系统管理任务设立角色,依据角色划分特权。典型的系统管理角色有系统管理员、安全管理员、审计管理员等。系统管理员负责系统的安装、管理和日常维护,如安装软件、增添用户账号、数据备份等。安全管理员负责安全属性的设定与管理。审计管理员负责配置系统的审计行为和管理系统的审计信息。一个管理角色不拥有另一个管理角色的特权。攻击者破获某个管理角色的口令时不会得到对系统的完全控制。
    5. 中科安胜安全操作系统
    6. 安胜安全操作系统是参照美国国防部《可信计算机系统评估准则》B2级安全需求和我国新颁布的《计算机信息系统安全保护等级划分准则》,结合我国国情和实际需求,自行开发的高级别安全操作系统,即安胜安全操作系统(SecLinux),并通过国家信息安全测评认证中心认证,同时获得公安部的销售许可。

     

    最小特权管理是SecLinux的一个特色,它使得系统中不再有超级用户,而是将其所有特权分解成一组细粒度的特权子集,定义成不同的"角色",分别赋予不同的用户,每个用户仅拥有完成其工作所必须的最小特权,避免了超级用户的误操作或其身份被假冒而带来的安全隐患。

    Internet安全

    Internet的发展可谓一日千里,而对Internet安全的要求却比Inerternet本身发展得更快。目前Internet上的安全问题,有相当多的是由于网络管理员对于角色权利的错误分配引起的。因此,最小特权原则在Internet安全上也大有用武之地。

    在日常生活里,最小特权的例子也很多。一些汽车制造厂制造汽车锁,用一个钥匙开车门和点火器,而用另一个钥匙开手套箱和衣物箱;停车场的服务员有安排停车的权而没有从汽车衣物箱里取东西的权力;同样是最小特权,可以给人汽车的钥匙而不给他大门的钥匙。

    在Internet上,需要最小特权的例子也很多,例如:不是每个用户都需要使用所有的网络服务;不是每个用户都需要去修改(甚至去读)系统中的所有文件;不是每个用户都需要知道系统的根口令(Root Password);不是每个系统管理员都必须知道系统的根口令;也不是每个系统都需要去申请每一个其他系统的文件等等。

    Internet上出现的一些安全问题都可看成是由于最小特权原则的失败。例如Unix上最常用的邮件传输协议Sendmail,它是一个庞大而又复杂的程序。这样的程序肯定会有很多隐患。它经常运行全部解密(Setuid)根目录,这对很多攻击者是很有利的。系统上运行的程序希望是尽可能简单的程序,如果是一个较复杂的程序,那么应该找出办法从复杂部分里去分开或孤立需要特权的模块。

    为了保护站点而采取的一些措施也是使用最小特权原则的,如包过滤系统就设计为只允许进入所需要的服务,而过滤掉不必要的服务。在堡垒主机里也使用了最小特权原则。

    最小特权原则还有助于建立严格的身份认证机制。对于所有接触系统的人员,按其职责设定其访问系统的最小权限;并且按照分级管理原则,严格管理内部用户帐号和密码,进入系统内部必须通过严格的身份确认,防止非法占用、冒用合法用户帐号和密码。具体实现用户身份认证时,可以通过服务器CA证书与IC卡相结合实现。CA证书用来认证服务器的身份,IC卡用来认证企业用户的身份等等。

    结束语

    最小特权原则有效地限制、分割了用户对数据资料进行访问时的权限,降低了非法用户或非法操作可能给系统及数据带来的损失,对于系统安全具有至关重要的作用。但目前大多数系统的管理员对于最小特权原则的认识还不够深入。尤其是对于UNIX、Windows系列操作系统下,因为系统所赋予用户的默认权限是最高的权限,例如Windows NT下的目录和文件的默认权限是Everyone(所有人)均具有完全的权限,而Administrator(系统管理员)则有对整个系统的完全控制。如果系统的管理员不对此进行修改,则系统的安全性将非常薄弱。

    当然,最小特权原则只是系统安全的原则之一,如纵深防御原则、特权分离原则、强制存取控制等等。如果要使系统的达到相当高的安全性,还需要其他原则的配合使用。

     

    参考资料

    • 樊国桢、陈祥辉、蔡敦仁,《数据库滥用轨迹塑模》

    • 总参通信部,《中华人民共和国国家军用标准》,1992年9月

    • 《安全从底层做起》,计算机世界报,第12期

    • 李波,《根上解决安全问题》

    • 王金涛,《构筑企业内部的钢铁长城》

    关于作者

    朱涛江:装备指挥技术学院研究生,研究信息对抗方向。您可以通过 quepy@sohu.com与他联系!

    原文地址:http://www.ibm.com/developerworks/cn/security/se-limited/index.html

    展开全文
  • 原则 4:最小特权 原则 5:分隔

    千次阅读 2009-10-08 21:50:00
    转自http://www.ibm.com/developerworks/cn/security/s-priv/index.html 摘要:最小特权原则规定:只授予执行操作所必需的最少访问权,并且对于该访问权只准许使用所需的最少时间。 c语言为程序员提供了很大的舞台...
  • 最小特权原则应用到 Windows XP 上的用户帐户发布日期: 2006年07月03日若要查看有关本...本页内容引言与管理特权相关的风险最小特权原则的定义LUA 方法的定义LUA 方法的好处风险、安全性、可用性及成本的权衡实现...
  • 系统安全原则最小特权

    千次阅读 2014-11-03 22:05:51
    最小特权原则是系统安全中最基本的原则之一。具体来说,指的是“在完成某种操作时,赋予系统主体(用户或进程)所必须的最小特权,确保系统由于事故、错误、篡改等原因造成的损失最小”。 最小特权原则一方面需要...
  • 最小特权原则是系统安全中最基本的原则之一,它限制了使用者对系统及数据进行存取所需要的最小权限,既保证了用户能够完成所操作的任务,同时也确保非法用户或异常操作所造成的损失最小。下文从安全操作系统及...
  • 对访问控制中"最小特权原则"的理解

    千次阅读 2006-06-15 22:38:00
    在网上看到许多资料介绍访问控制中的一个基本原则“最小特权原则”是“在需要时才给用户分配所需的权限”,感觉这样如果从字面理解的会产生歧义,如果不在授权时为操作者指派特定的权限,那么在操作者对某个资源进行...
  • 遵守最小特权原则的程序不会尝试拒绝对资源的合法请求,而是根据合理的安全指南授予访问权限。    Windows XP 帐户  若要了解 LUA 方法的工作原理,应了解 Windows XP 中管理帐户和非管理帐户之间的区别,...
  • 关注公众号:AWS爱好者(iloveaws) 文 | 沉默恶魔(禁止转载,转载请先经过作者同意) ...Hello大家好,欢迎回来,我们今天的课程内容是 最小权限原则,对于解决方案架构师或者安全工程师来讲,在分配访问...
  • 这牵涉到Linux的“最小特权”(least priviledge)的原则。Linux通常希望进程只拥有足够完成其工作的特权,而不希望赋予更多的特权给它。从设计上来说,最简单的是赋予每个进程以super user的特权,这样进程就可以想做...
  • 如何为每个使用者分配相应的权力(即授权)将是本文将要分析的一个重要原则--最小特权原则(Least Privilege Theorem)。 2、最小特权原则简介 最小特权原则是系统安全中最基本的原则之一。所谓最小特权(Least ...
  • Android系统最小权限原则

    千次阅读 2013-04-10 17:31:43
    最小特权原则是系统安全中最基本的原则之一。具体来说,指的是“在完成某种操作时,赋予系统主体(用户或进程)所必须的最小特权,确保系统由于事故、错误、篡改等原因造成的损失最小”。 最小特权原则一方面需要...
  • c++程序员面试题目

    千次阅读 2012-05-14 22:16:23
    之所以使用引用是为了用适当的工具做恰如其分的事, 体现了最小特权原则. 6. 说一说C与C++的内存分配方式?1)从静态存储区域分配。内存在程序编译的时候就已经分配好,这块内存在程序的整个运行期间都存在,如...
  • 4 最小权限原则 最小权限原则(最早由 Saltzer 和 Schroeder 提出): 每个程序和系统用户都应该具有完成任务所必需的最小权限集合。 限制代码运行所需的安全权限,有一个非常重要的原因,就是降低你的代码在...
  • “根据需求制定切当的ACL(Access Control List), 力求以最小特权运行程序“, 这是Micheal在《Writing secure code》中提出来的原则。我谨记!但是这两天QA报出来一个多用户操作的问题, 让我不得不寻求扩大...
  • 怎么在云中实现最小权限? 根据云计算权威组织云安全联盟(CSA)对241位行业专家的最新调查,云计算资源配置错误是导致组织数据泄露的主要原因。 那么造成这种风险的主要原因是什么?由于数据规模巨大,因此在云中管理...
  • 软件安全开发(2)

    2021-08-18 15:50:19
    理解最小特权、权限分离等安全设计的重要原则 理解攻击面的概念并掌握降低攻击面的方式 什么是威胁建模 威胁建模是了解系统面临的安全威胁,确定威胁风险并通过适当的缓解措施以降低风险,提高系统安全性的过程 ...
  • 密码学应用----访问控制

    千次阅读 2020-07-09 19:20:19
    访问控制模型的基本原则: (1)最小特权原则:根据主体所需权力的最小化分配,能少不多。 (2)最小泄露原则:对于权限的行使过程中,使其获得的信息最小。 (3)多级安全策略:对于信息安全级别要加以考虑,避免高...
  • 什么是ACL? 访问控制列表简称为ACL,访问控制列表使用包过滤技术,在路由器上读取第三层及第四层包头中的信息如源地址,目的地址,源端口,目的端口等,根据预先定义好的规则对包进行... 访问控制列表使用原则 ...

空空如也

空空如也

1 2 3 4 5 ... 20
收藏数 5,948
精华内容 2,379
关键字:

最小特权原则