我的一个朋友是医生，与其他医生共享他的办公室（他们都是精神病医生）。 他们正在寻找一种不昂贵和安全的方式，通过局域网在服务器（优先运行Ubuntu Linux）上共享和存储文件（基本上只包含纯文本的注释和报告）。
他们需要能够dynamic地设置某些文件的权限：有时医生A需要给某个文件读取权限给医生B并再次删除。 或者医生B和C需要读取/写入医生A根本无法访问的特定文件。
除此之外，即使这个人可以获得对服务器的物理访问权限，也没有其他人可以阅读这些文件，这是非常重要的。
他们不会记住数百个密码，所以我也在寻找某种与操作系统无关的SSO解决scheme，甚至可能使用硬件令牌。
在客户端，他们都有不同的工作站（Windows XP，Linux和OSX）。
我正在考虑将TrueCrypt与eTokens结合使用的解决scheme，因此无论文件保存在何处，它们总是被encryption，只能被有权限的人读取。
有没有人有更好的主意，或者你能指点我一个类似的设置/如何？ 或者你会在这种情况下自己设置一个智能Intranet Web应用程序？
我同意Schmitty23 ..我认为手动pipe理权限是一个错误..它很容易出错，难以pipe理。 我build议一个简单configuration的文件pipe理系统。
– > http://www.knowledgetree.com/
– > http://www.openkm.com/
– > http://contineo.sourceforge.net/features.html
– > http://www.alfresco.com/
回应哈维尔的评论。
a-没有DMS像“文件/打开/保存”那样直观，但是权限比文件系统安全性更容易处理。 设置简单，用户将调整。
– >他们会喜欢版本控制。
b-我不知道encryption，但我想操作系统可以encryption文件系统。 一些系统可以将文档本身存储在数据库中，也可以encryption。
c-我没有使用过这些…他们find了“Ubuntu文档pipe理”。 我曾经使用过Plone，因为这是一种痛苦，所以我没有join。
听起来像一个非常困难的情况下处理，而不使用一些具有文件pipe理function的集成包。 我自己的公司出售一种我们出售给医疗机构的产品来创build\扫描，存储和pipe理图像和文本信息，还有一些function只是为了保护信息而devise的。 顺便说一下，这样的组织的一个大问题是HIPAA的规定，这就是为什么我假设你的客户想要encryption文件。
顺便说一句，HIPAA不仅对数据保护有严格的要求，而且要求对数据进行访问，所以简单地对数据进行encryption可能是不够的。
除此之外，试图让非技术人员“完全控制”他们必须不断pipe理和更改其他用户的权限（并且可能是单个文件的encryption状态）的文件和文件夹，IMHOO是令人沮丧的秘诀。
还有一点评论..我的经验告诉我，医生types喜欢他们完全控制他们的信息，但也从来不想理解为什么问题出现在devise不当的IT系统中，特别是当他们决定使用它。 所以他们可能会说他们想要不断地监视他们的文件，并且pipe理其他用户的访问，但实际上可能不会做得很好，给他们或者办公室的其他用户带来问题。
如果他们坚持走这条路线，你可能想通过股票来pipe理访问; 给每个提供者一个自己的份额，私人给他们，只有他们有权限。 让他们在那里存储所有文件。
制作一个共享文件夹，也许为每个用户和一个“公共”子文件夹的子目录。 对于每个用户，将驱动器映射到个人子文件夹（shared \ doctorX）并将其映射到公用文件夹（shared \ public）
当医生想要访问文档时，他们可以移动或复制他们的私人目录 – 如果他们希望一个用户看到该文件，则共享\ Doctorx文件夹，或者如果他们希望所有用户看见。
encryption仍然需要以某种方式进行pipe理。 但是，这给每个提供商一个简单的映射驱动器，让他们自己的文档，logging其他提供商正在提交给他们，并指出其他提供商希望所有人都看到。
我想你已经描述了多级安全的最简单的用例。 在Fedora中有一个MLS的实现，但我对此一无所知。
安全是一个痛苦。 总是会有权衡。
SAMBA正确configuration可能会解决您的问题。 想象一下，每个医生都有两个股份，一个是专有的，另一个是与所有其他医生共享的。
由于我没有看到多个密码的方法，每个医生都必须使用PasswordSafe等密码pipe理应用程序pipe理密码列表，并将密码DB保存在TrueCrypt卷中的私人共享中。 他们最多需要记住三个密码：一个用于他们的机器，另一个用于安装SAMBA共享，另一个用于密码pipe理应用程序。
在私人分享中，他们将保持一个TrueCrypt卷包含他们的只有眼睛的信息。 在TrueCypt卷中，每个病人都有一个目录。 或者他们将有一个TrueCrypt卷每个病人加一个pipe理。
在共享共享中，他们将为每个能够查看信息的医生组合创build一个目录。 是的，我知道，会有组合爆炸。 这个所谓的解决scheme不能缩放。 假设有10位医生，这意味着2 ^ 10（= 1,024）个可能的目录。 但我认为这种做法要小得多。 这些目录应该有一个标准化的命名约定，表明目录与谁共享。 每个目录将定期扫描，以确保适当的权限得到执行。
TrueCrypt的问题是，只有一个人同时安装特定的卷。
你可以从这里把剩下的东西从肉里捞出来。