Home | About | Sematext search-lucene.com search-hadoop.com
 Search Hadoop and all its subprojects:

Switch to Plain View
Accumulo >> mail # user >> Security and data design advice on structuring data on accumulo


+
Edmon Begoli 2012-08-08, 20:08
+
Marc Parisi 2012-08-08, 22:29
+
Edmon Begoli 2012-08-09, 19:44
+
Josh Elser 2012-08-10, 02:19
+
Adam Fuchs 2012-08-10, 12:52
+
Benson Margulies 2012-08-10, 12:56
+
Adam Fuchs 2012-08-10, 13:02
+
David Medinets 2012-08-10, 13:54
+
Edmon Begoli 2012-08-10, 14:47
Copy link to this message
-
Re: Security and data design advice on structuring data on accumulo
That's what I meant, user*doctors.

It's not enough to say "healthteam", you have to qualify it by user too:
"adamhealthteam".

On 8/10/12 9:02 AM, Adam Fuchs wrote:
>
> I guess I should have specified that the access time labels should be
> used in conjunction with the role labels, like
> "(adamsHealthTeam&(regularCheckup|illnessEvaluation))|(massStateResearcher&populationStudy)".
>
> Adam
>
> On Aug 10, 2012 8:56 AM, "Benson Margulies" <[EMAIL PROTECTED]
> <mailto:[EMAIL PROTECTED]>> wrote:
>
>     On Fri, Aug 10, 2012 at 8:52 AM, Adam Fuchs <[EMAIL PROTECTED]
>     <mailto:[EMAIL PROTECTED]>> wrote:
>     > Not sure I understand why this gets into n*m roles. Can you
>     elaborate?
>     >
>     > The question of when your physician should have access seems
>     like it could
>     > be represented by just a few labels, like "regularCheckup",
>     > "illnessEvaluation", and "populationStudy". Those labels could
>     then be tied
>     > to an auditing system that could verify appropriateness of
>     access over time.
>
>     And if you change doctors? Maybe that's a job for some sort of
>     role/group model.
>
>
>     >
>     > Adam
>     >
>     > On Aug 9, 2012 10:19 PM, "Josh Elser" <[EMAIL PROTECTED]
>     <mailto:[EMAIL PROTECTED]>> wrote:
>     >>
>     >> I've thought quite a bit about the approach you've outlined
>     previously..
>     >>
>     >> The main caveat I've always struggled to overcome is how to
>     encapsulate
>     >> *when* a physician should have access to your records. This
>     expands the
>     >> problem into n*m roles which becomes difficult to manage inside
>     Accumulo,
>     >> especially as time elapses.
>     >>
>     >> On 8/8/2012 6:29 PM, Marc Parisi wrote:
>     >>>
>     >>> Just some ideas and thoughts....
>     >>>
>     >>> With a system I'm building I have code to take care of user
>     roles. Roles
>     >>> will define visibilities, how analysis is performed, information
>     >>> sharing, etc. I have a particular role for sharing. I also
>     have an area
>     >>> of interest, usually assigned to a physician role, therefore
>     only a
>     >>> physician's office can see certain data from it. The data
>     corresponding
>     >>> to a given person can be accessed by that person ( if they
>     have app
>     >>> access ), the physician that created it, and other physicians
>     ( with a
>     >>> different area of interest ) with whom the user wants to share
>     their
>     >>> data. Each area of interest will be cryptographically secured. Our
>     >>> approach will utilize multiple crypto technologies. I would
>     suggest
>     >>> making crypto your last stop. Focus on getting
>     >>> the visibility hierarchy designed. HIPAA requirements can come
>     later.
>     >>>
>     >>> In my approach, there is no elevation of fields per se.
>     Instead, there
>     >>> are visibiilities for all assigned parties,so in my case it is
>     a matter
>     >>> of labeling. The data can have hierarchies, and each hierarchy has
>     >>> different labels to control access.
>     >>>
>     >>> " Patient demographic fields are PHI (personal health
>     information) and
>     >>> these should not be visible to all who want to perform
>     analysis, but
>     >>> only to main administrators,
>     >>> patient and maybe physician. I assume these would have to have
>     >>> separate authorization label. "
>     >>>
>     >>> Yes. I think this is where roles will help. Assign roles and
>     >>> visibilities to those roles. As of right now, I'm putting
>     ephemeral data
>     >>> in my visibilities ( user ID for a physician, among other
>     things ). I
>     >>> will probably move this to the qualifier and take a more
>     simple approach
>     >>> to visibilities.
>     >>>
>     >>> Each role has different actions. Right now I have four
>     actions; syncing,
>     >>> querying, deleting, and sharing. You don't have to capture
>     actions, but
+
Adam Fuchs 2012-08-10, 16:05
+
Josh Elser 2012-08-10, 16:28
+
David Medinets 2012-08-11, 03:38
+
Edmon Begoli 2012-08-10, 16:33
+
Marc Parisi 2012-08-10, 17:00
+
Christopher Tubbs 2012-08-11, 01:05
+
Edmon Begoli 2012-08-10, 16:02