[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

[LDM #EOM-644646]: LDM data acccess control question



Brice,

I can count on you to have interesting use-cases. :-)

Why not just have a separate computer run an LDM that requests only the 
public-available data and to which your clients can only connect. That way you 
don't have to worry about multiple LDM-s on the same computer or changing the 
well-known port-number.

> Steve,
> 
> I've got a situation here at JSC that concerns controlling external user
> access to data in the LDM queue.  As you already know from 'painful'
> experience, our LDM usage/installation here is 'non-standard', so here's
> what I've run into and what I am thinking about how to solve the problem.
> If you have any suggestions, I would very much appreciate them.
> 
> We use LDM to retrieve and deliver a lot of internal data streams in
> addition to the standard NOAAPort.  We have some external customers
> who come in from the Internet to get selected data from our queue.
> Because of NASA policies on data protection, specifically that requests
> for data from NASA systems be authenticated and the data leaving NASA
> systems be encrypted in transit to the authorized user, we are running
> the external customers LDM sessions through SSH tunnels.
> 
> The issue that has arisen is that because the SSH-enabled LDM streams
> come up essentially inside our platforms, we cannot use the normal LDM
> 'allow' controls to restrict what data they can see.  We know they are
> authenticated and authorized, but not necessarily for all the data that
> flows through our queue.
> 
> My proposed solution is to run a second, 'public' LDM server, listening
> on a different port and allowing the external customers to connect only
> to that server.  In turn that server would request only the 'public'
> data from our internal servers.  I've looked at the 'Running Multiple
> LDM-s' documentation and it seems like this would work and wouldn't
> require *too* much additional effort and maintenance.  More effort for
> O/S support to set up and some for us to configure.
> 
> My questions to you are:  does this sound reasonable?  Are there better
> ways to do this?
> 
> Thanks,
> 
> Brice
> 
> Brice Biggerstaff, CISSP
> JSC Weather Decision Support System
> Software Engineering Support Lead
> 281-853-3011 (w)
> 713-764-2601 (p)
> address@hidden (alpha text pager)
> address@hidden
> 
> Res Confacti Erimus
> 
> *'We get things done.'*

Regards,
Steve Emmerson

Ticket Details
===================
Ticket ID: EOM-644646
Department: Support LDM
Priority: Normal
Status: Closed