SQL security over the LAN
-
@flaxking said in SQL security over the LAN:
@tonyshowoff said in SQL security over the LAN:
@flaxking said in SQL security over the LAN:
@tonyshowoff said in SQL security over the LAN:
@flaxking That may work and is worth a try, but it's likely not to work because the client is passing along to SQL Server and it's not known whether or not they implemented, or allow, encrypted traffic within their SQL Server connection library. Even if implemented in the library, it doesn't mean the client allows it, and even may be intentionally disabled for God only knows what reason. It isn't an SQL client, it's an application which just connects to SQL Server or passes raw SQL along to an application server to avoid client connection licensing limits.
How would that avoid licencing? The MS SQL licencing doesn't care how a user connects, you have to get CALs for the actual users using it no matter the method used. (Unless using SQL Express)
Because it opens one connection between the application server and the SQL Server rather than a new one for every single client. You can avoid user CAL issues because it's one connection from one user.
I can't speak to there possibility being a point in time when this was true, but it is not true now. You have to get CALs for each actual person, even if they themselves are not in direct communication with the MS SQL Server
I am aware but it isn't relevant, that's just why people do it in the ERP world in addition to having license control over their own client application. There's no inherent transparent encryption with a third party library connecting to SQL Server though. It should be straight forward from the development perspective considering they must be using a fairly modern one to be using SQL over SMB2, but if the company is basically dismissing concerns over encryption by saying "it's up to you to secure your network" that's basically saying "what's encryption? We're morons."
-
@tonyshowoff said in SQL security over the LAN:
but if the company is basically dismissing concerns over encryption by saying "it's up to you to secure your network" that's basically saying "what's encryption? We're morons."
I have a suspicion that this is true. I feel like there are maybe two sides to software development, there is the functional aspect of the SW itself, but then there is how it incorporates into the overall IT plan for a target business. It feels like all of this company's development resources go into the first category, and none in the second.
-
@Donahue said in SQL security over the LAN:
@tonyshowoff said in SQL security over the LAN:
but if the company is basically dismissing concerns over encryption by saying "it's up to you to secure your network" that's basically saying "what's encryption? We're morons."
I have a suspicion that this is true. I feel like there are maybe two sides to software development, there is the functional aspect of the SW itself, but then there is how it incorporates into the overall IT plan for a target business. It feels like all of this company's development resources go into the first category, and none in the second.
In general, actual software developers have no idea what IT is. They shouldn't. Otherwise they would be in IT. A good software development house should have staff on hand to handle how the software works in relation to IT needs though.
-
@JaredBusch said in SQL security over the LAN:
A good software development house should have staff on hand to handle how the software works in relation to IT needs though.
LOL
-
@JaredBusch said in SQL security over the LAN:
@Donahue said in SQL security over the LAN:
@tonyshowoff said in SQL security over the LAN:
but if the company is basically dismissing concerns over encryption by saying "it's up to you to secure your network" that's basically saying "what's encryption? We're morons."
I have a suspicion that this is true. I feel like there are maybe two sides to software development, there is the functional aspect of the SW itself, but then there is how it incorporates into the overall IT plan for a target business. It feels like all of this company's development resources go into the first category, and none in the second.
In general, actual software developers have no idea what IT is. They shouldn't. Otherwise they would be in IT. A good software development house should have staff on hand to handle how the software works in relation to IT needs though.
Actually you're describing how bad software is written, in my experience of 22ish years programming professionally, the programmers who know about IT and hardware do the best over people who know neither. I'm not an IT person, and yet I get hired to do things a lot of IT people couldn't figure out, largely because they were inexperienced, and it's not my job, I just understand networks, domains, and so forth enough to get by but it also had helped me write good client-server programs, know how to authenticate and deal with AD, and so on. And I'm not the only one, a lot of good programmers do this work a lot, either as favours or between projects.
Just because a development company has an IT person doesn't mean it's because the programmers need them because they don't understand IT, it's usually because the programmers are too busy to deal with IT problems. Good programming talent is incredibly hard to find, not necessarily because it's rare, but because the market is overflooded with incompetence, just like IT is, especially with outsourcing to the third world and young people who think they know everything because they've changed video cards or configured printers (this applies to IT and programming). Just look at Spiceworks.
If you want good programming with concepts of how security works such as GPO, and good network design (such as IRC networks, MySQL clusters, etc), and an understanding of load balancing, how infrastructure works and how it relates to your programming, how data travels over networks and why encryption matters, etc you need a solid IT understanding. You can't just try to find some IT person who happens to know what you need to know so you can write your programs, then try to explain to them any issues or design questions you have with your project only for them to have no idea how to program. You need to be able to answer these things yourself and all good programmers are very good IT people, some of us just can't crimp rj45 connectors, I can't see those tiny ass wires!
I have known programmers who don't know the first thing about IT, they were all terrible, wrote terrible software, and shrugged at essentially all security concepts. The descriptions in posts above about the incompetence of companies not understanding network encryption (that ERP company) and not understanding the basics of network latency (Eaglesoft) and not understanding why a program needing local admin rights is stupid (Eaglesoft) are not virtues to suggest they should fall on some IT guy to solve the problem rather than the programmer know what he's doing.
Anyway, it's like suggesting IT people are best that don't know scripting because then they'd be in programming. While really experienced IT people will certainly know things even good programmers don't, they do have a hell of a lot of knowledge overlap, it comes with the territory.
-
@tonyshowoff While it would be great if everyone knew this, that is unrealistic.
The best software comes from a team with software development done by programmers and someone form IT to apply the needed skills to the development process.
All the examples above are absolutely not done this way. That is the problem.
For a small software house, they won't have the overhead for that separate person, so yeah, then they need someone like you to wear both hats.
-
@JaredBusch said in SQL security over the LAN:
@tonyshowoff While it would be great if everyone knew this, that is unrealistic.
The best software comes from a team with software development done by programmers and someone form IT to apply the needed skills to the development process.
Only really huge projects ever have specialists on them like IT people, and those projects are almost always garbage. I see no connection. RFCs for network communication are not written by non-programmers, not the successful ones anyway. And infrastructure goes and in hand with that, such as the origins of ARP tables. There are IT centred programmers, but IT people are not consultants on projects in of themselves, not that I've ever seen personally for certain, but it probably happens for whatever reason.
All the examples above are absolutely not done this way. That is the problem.
For a small software house, they won't have the overhead for that separate person, so yeah, then they need someone like you to wear both hats.
I worked at AOL, the understanding of IT vs no understanding of it is reflects in the garbage scale of much of their network through the late 90s and early 2000s. They often just refused to listen to programmers and IT people had a weird smugness I'd never seen before or since.
I think you're over valuing IT people from network and infrastructure managers and maintainers to making them consultants in software and that's really not done.
-
@tonyshowoff I think you're either misunderstanding what IT is, or why an IT member would be there.
-
@Obsolesce said in SQL security over the LAN:
@tonyshowoff I think you're either misunderstanding what IT is, or why an IT member would be there.
Define it for me then.
-
@tonyshowoff said in SQL security over the LAN:
@Obsolesce said in SQL security over the LAN:
@tonyshowoff I think you're either misunderstanding what IT is, or why an IT member would be there.
Define it for me then.
-
@Obsolesce said in SQL security over the LAN:
@tonyshowoff said in SQL security over the LAN:
@Obsolesce said in SQL security over the LAN:
@tonyshowoff I think you're either misunderstanding what IT is, or why an IT member would be there.
Define it for me then.
So according to SAM's words, "the purpose of IT is to deliver business infrastructure, it's a business unit, and what it gives to the business is the infrastructure for operating the business."
And I said:
"I think you're over valuing IT people from network and infrastructure managers and maintainers to making them consultants in software and that's really not done."Yeah, I have no idea what IT is.
-
Like I said above, IT and software engineering have a lot of knowledge overlap and I think that's why outsiders are confused as SAM talks about. There's a similar issue in web development, confusion with web design. People think because I make web apps that I must be a web designer, can make logos, etc but being a designer almost always implies that you're terrible at programming and visaversa. That contrast isn't true between IT and software engineering in the reverse, there's no significant sample size I've ever noticed where IT and software engineers have totally incompatible skills and knowledge, most IT people I've known just hate programming, they do the scripting they need to do and hate the rest. And the reverse is, programmers who don't understand infrastructure or how businesses benefit from networks other than mantras about client-server architectures are just bad programmers.
-
All this is my opinion. I see IT as managing and recommending tools that the business uses to function as a business. I see software as just one of those tools. Software development simply develops that software, and generally from a point of view of a closed system product. As a software developer, I would guess the main responsibilities would be to make sure the software functions for whatever business purpose it was created for. But as IT, I try and make all the pieces fit together so that there is a comprehensive picture of how we do business. In my case of the ERP, they are focused on making the product functional at a basic level, but completely miss other business needs, such as security, even though the best place for security measures are at that same software level.
It's like software developers are a car manufacturer, and IT is the transportation planner. You CAN make a car without regards to what kind of road it will be driven on, or if there are any relevant laws that should be part of the original design. But that would likely be an inferior product to something that we designed from the ground up to not only get you from point A to point B (the actual purpose of a car), but to also incorporate things like safety features, or navigation, or whatever so that the overall experience of the user was more than the basic functionality of the actual transportation.
