Napkin design...let's go LAN'less
-
@dafyre said:
What makes a VPN (ignoring ZT and Pertino for the moment) any different than a Jumpbox in that light?
A lot of things. One is that it is purely designed (all VPNs which means ZT and Pertino too) with the sole intent of replicating a LAN where a physical limitation would have prevented it before. The name VPN itself means that. The purpose of a VPN is to encrypt data in flight, nothing more. It "can" be leveraged to do more than that which is why using a VPN does not necessarily stop you from being LANless, but the fundamental goal of a VPN is LAN extension through data encryption. That's what makes it a VPN.
A Jump Box is a user centric authentication mechanism used as an aggregation and control system for security. It mimics many mechanisms in a VPN but is not a VPN. A VPN extends a LAN, a Jump Box proxies to it. Proxying with user authentication vs. network extension using many of the same tools and some not the same.
-
@scottalanmiller said:
@dafyre said:
What makes a VPN (ignoring ZT and Pertino for the moment) any different than a Jumpbox in that light?
A lot of things. One is that it is purely designed (all VPNs which means ZT and Pertino too) with the sole intent of replicating a LAN where a physical limitation would have prevented it before. The name VPN itself means that. The purpose of a VPN is to encrypt data in flight, nothing more. It "can" be leveraged to do more than that which is why using a VPN does not necessarily stop you from being LANless, but the fundamental goal of a VPN is LAN extension through data encryption. That's what makes it a VPN.
Okay, that above paragraph makes sense.
A Jump Box is a user centric authentication mechanism used as an aggregation and control system for security. It mimics many mechanisms in a VPN but is not a VPN. A VPN extends a LAN, a Jump Box proxies to it. Proxying with user authentication vs. network extension using many of the same tools and some not the same.
Wouldn't an RD Gateway function essentially the same as a JumpBox (differences in technology & OS choice aside)? It handles the user authentication, and then bounces the user to the specified host that they wanted to connect to -- the same as a JumpBox.
-
@dafyre said:
Wouldn't an RD Gateway function essentially the same as a JumpBox (differences in technology & OS choice aside)? It handles the user authentication, and then bounces the user to the specified host that they wanted to connect to -- the same as a JumpBox.
Yes, an RDG can be a form of jump box.
-
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?
-
@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
-
@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.
-
@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.
