Napkin design...let's go LAN'less
-
@scottalanmiller said:
@dafyre said:
Your services are designed to be accessed via the internet...and those that can are cloud-hosted, right?
And one of the ways to access them is.... RDP
Touche, lol.
-
@coliver said:
@dafyre said:
Time to suddenly reverse gears, ha ha ha. Why would you need a JumpBox or RDGateway in a LANless design (Legacy apps and lab setups aside)?
Your services are designed to be accessed via the internet...and those that can are cloud-hosted, right?
Centralized authorization/authentication and logging. You can easily know who logged into what system at what point in time. This is a bit harder, although not impossible, with disparate logs and systems. You also only have to lock people out of one location when/if they leave or are let go.
That is what tools like ELK are for. 8-) Centralized logging. But you do have a point about locking people out of multiple systems when they leave / are let go.
-
@scottalanmiller said:
ics many mechanisms in a VPN but is not a VPN. A VPN extends a LAN, a Jump Box proxies to it. Proxying with user
As for the Jump boxes, Why make administration something that can be done from anywhere? Sure, those managed boxes might provide other services to the internet at large, like web service, but why open port 22 to the internet at large? Instead you can put all those port 22's behind the jump box allowing logon only from the jump box. Hopefully this provides better security.
-
@Dashrender said:
@scottalanmiller said:
ics many mechanisms in a VPN but is not a VPN. A VPN extends a LAN, a Jump Box proxies to it. Proxying with user
As for the Jump boxes, Why make administration something that can be done from anywhere? Sure, those managed boxes might provide other services to the internet at large, like web service, but why open port 22 to the internet at large? Instead you can put all those port 22's behind the jump box allowing logon only from the jump box. Hopefully this provides better security.
I thought that was kind of the point. Proxy the management through a jump box.
-
@coliver said:
@Dashrender said:
@scottalanmiller said:
ics many mechanisms in a VPN but is not a VPN. A VPN extends a LAN, a Jump Box proxies to it. Proxying with user
As for the Jump boxes, Why make administration something that can be done from anywhere? Sure, those managed boxes might provide other services to the internet at large, like web service, but why open port 22 to the internet at large? Instead you can put all those port 22's behind the jump box allowing logon only from the jump box. Hopefully this provides better security.
I thought that was kind of the point. Proxy the management through a jump box.
Exactly.
-
@scottalanmiller said:
@coliver said:
@Dashrender said:
@scottalanmiller said:
ics many mechanisms in a VPN but is not a VPN. A VPN extends a LAN, a Jump Box proxies to it. Proxying with user
As for the Jump boxes, Why make administration something that can be done from anywhere? Sure, those managed boxes might provide other services to the internet at large, like web service, but why open port 22 to the internet at large? Instead you can put all those port 22's behind the jump box allowing logon only from the jump box. Hopefully this provides better security.
I thought that was kind of the point. Proxy the management through a jump box.
Exactly.
Yup, that's where I was going with that. It has nothing to do with being LANless, and as Scott already said, everything to do with security.
-
LAN'less napkin design, something like this?
-
@travisdh1 Who/what is in charge of "controlling" all those users & their access?
-
@FATeknollogee said:
@travisdh1 Who/what is in charge of "controlling" all those users & their access?
ownCloud.
-
@scottalanmiller said:
@FATeknollogee said:
@travisdh1 Who/what is in charge of "controlling" all those users & their access?
ownCloud.
Or the System Admin who manages that server.
Edit: Ideally the oC Server would be integrated into some form of central authentication -- AD, AzureAD, or something.
-
@scottalanmiller said:
@FATeknollogee said:
@travisdh1 Who/what is in charge of "controlling" all those users & their access?
ownCloud.
I assumed the users will access more than oC even though the drawing doesn't show that?
-
@dafyre said:
@scottalanmiller said:
@FATeknollogee said:
@travisdh1 Who/what is in charge of "controlling" all those users & their access?
ownCloud.
Or the System Admin who manages that server.
Edit: Ideally the oC Server would be integrated into some form of central authentication -- AD, AzureAD, or something.
Maybe not ideally. If that is the only service, use it as the authentication authority.
-
@FATeknollogee said:
@scottalanmiller said:
@FATeknollogee said:
@travisdh1 Who/what is in charge of "controlling" all those users & their access?
ownCloud.
I assumed the users will access more than oC even though the drawing doesn't show that?
Ah, well that's different then.
-
@dafyre said:
@scottalanmiller said:
@FATeknollogee said:
@travisdh1 Who/what is in charge of "controlling" all those users & their access?
ownCloud.
Or the System Admin who manages that server.
Edit: Ideally the oC Server would be integrated into some form of central authentication -- AD, AzureAD, or something.
Right. If you have more than a single server and/or service it'd be easier to manage with LDAP/AD/AzureAD.
-
@scottalanmiller said:
@FATeknollogee said:
@scottalanmiller said:
@FATeknollogee said:
@travisdh1 Who/what is in charge of "controlling" all those users & their access?
ownCloud.
I assumed the users will access more than oC even though the drawing doesn't show that?
Ah, well that's different then.
I should've just labeled the server as "Services" instead of "OwnCloud"
