It's not a question of what you can do, it's a question of what can the IT department be prevented from doing. The difference between wiping company data and wiping the whole phone just being different buttons does not reassure me.
This is how you do it - from MS link I posted earlier
"Enable your users to more securely access corporate information using the Office mobile and line-of business apps they know, while ensuring security of data by helping to restrict actions like copy, cut, paste, and save as, to only those apps managed by Intune."
If you restrict actions like copy, cut, paste, saving, screenshots, etc then you keep the data inside Office Mobile. Then you just remove the Office Mobile app remotely.
Are you able to enable remote removal of the app with just this feature?
You actually dont even have to do that. If they cannot login they cannot get to any of the data.
Assuming an encrypted cache, this sounds like a viable option. We have 100 Intune licences, so I can insist on being one of the users managed by Intune rather than Office365 MDM. But based on my recent experiences, I'm not too keen to have email or Teams on my phone.
what experience is that?
Nothing to do with the application, just to do with being always working. I did a 108 hour week followed by a 90 hour, followed by a 70 hour. I've now removed all work communication from my phone in order to try to get some peace when I can.
Allowing an SSH connection to the managementVM from the Internet
I have not tried this approach yet, and it appears more risky than the Screen Connect approach, since SSH to that VM would be open to the Internet. Unless I'm missing some benefit to this approach, I'll not be using it.
Use a strong key, lock to your IP. Very safe. Add Fail2Ban, of course.
Or add Salt and open/close based on need so it doesn't stay open.
Fail2ban doesn't work with keys.
But it would work normally with people attacking using non-keys, would it not? Or am I missing something about what it would do?
Why would you not require keys? Not making them mandatory defeats the purpose of using them.
I think he means - if a hacker is trying to use a password on a system setup to only allow keys - the fail2ban will block those users, or won't it?
No. It's dropped before fail2ban even sees it.
Oh, makes sense. There is no "attempt" like with a password, it is "already blocked."
That's a lot of investment for a system like that. If you have hundreds of customers, it can make sense. But it takes a lot of customers to recoup the lost time into that system. It can work out well for a traditional MSP, but depends on large scale standardization to justify the investment.
I don't know about hundreds of customers. The number of end points might be more relevant. For me at about 10 MSP customers I can justify the investment. When you look at the time it takes to set up something like a zabbix server and maintaining a WSUS server vs not having to that helps make it worth it. Missed revenue because you didn't have a system in place to capture every minute hurts.
It would be a blend, I'm sure. A single customer with a million end points wouldn't make sense because you'd use more traditional tools in a single customer scenario. And a hundred with only one end point each wouldn't do it either. So some combination of enough end points for volume and enough customers for complexity put together.
We use NextCloud, then only back that up, not the remote user devices.
Are you running your instance of NextCloud in a VPS with extra block storage for your files, or using their enterprise plan?
We run out own.
Forgive me for seeming thick, but you mean on your own hardware in your office or at a data center?
We never run on premises for production.
I figured not; thus, they're at a colo.
No, we use cloud computing.
Somehow I'm confused, so you are running your NextCloud in a cloud server instance like Vultr?
I'm assuming you're using the native sync clients? Are you using both Windows and Linux clients or just Linux? I've tried the Windows one on a couple laptops and found that the synching was really clunky and not working well. Have you run into any issues?
Both. All Linux internal, it's rock solid. Some Windows for external users, and they do have some issues. But... that's expected, it's Windows.
Also gives you (if you use GIT like we do) a record of when the port was opened, why and when it was closed again.
How does that work?
You commit your change to your local file system on your workstation. Then you commit it to the GIT repo. When you do this, GIT stores your change as well as the previous state of the system and you add a comment when you commit. This gives you a chance to say "Opening port to work on PBX" or whatever. Then when you are all done, change the firewall back, commit it, comment again saying you are done and closing it and it closes itself.