Hi Rhea, Adding some points to the very good answers above. QGIS is already deployed in very security sensitive organizations and has been assessed against vulnerabilities. I obviously can't list them publicly here. Some are public, like the NSA, that even publishes some plugins, but also funded some parts of the authentication system.
Its desktop component stays however a generic desktop tool, and as such will be able to interact with the OS it is installed on. Just like blender or FME or Arcxx that also have python scripting. I have seen deployment in sanboxes through virtualization tools that can help too. Like QGIS served through web streaming or as a remote app ( VMware stuff or vnc or similar stuff) There are several ways of addressing your concerns in QGIS itself. Most will rely on creating a specific configuration for your organisation. You will be able to deploy a preconfigured QGIS that can almost handle all this A few examples - configure QGIS with a dedicated user agent name and have the IT team filter the trafic they allow using their firewall - audit the plugins you will use and ship them with your install packages, or deploy an internal repository - use the awesome "constrained settings" script funded by a french ministry to prevent users from drifting away from this configuration - you can customize the UI so that average user just can't launch the python console. Any advanced user will be able to circumvent this, but it's a good start. -if you are really into security, don't focus on your customer's fears, but on the real criticity of a GIS infrastructure. Securing the data source connections, configuring mandatory encrypted keyrings is often the weakest part. Python scripting capabilities us present in most software.and must be secured by the OS and the IT. You can secure QGIS and have user send QGIS projects by mail with plain text credentials if you don't handle this. This should fear your customer more than potential python scripts. Another point. I have seen over constrained QGIS based deployments for "security reasons" . They showed up some side effects: - user were too constrained, when GIS work supposes to be able to handle quite complex tools (SQL queries, cli tools, heavy geospatial computing). They were so locked that they ended up in really trying shadow IT solutions. - the configuration work was too heavy and done as a one time project. the IT department could not follow the security updates of QGIS and it's dependencies , leading to severely outdated software in production. Security is also a matter of being able to update frequently to fix vulnerabilities, which we offer in every monthly release. I've conducted a few of such enterprise wide deployment and I confirm you that you can find professional support in the commercial companies that provides such services. You can find them listed on our website. (Disclaimer, I have no direct interest here and speak as a steering committee member) Best regards , and let us know how it goes Régis Le ven. 3 nov. 2023, 10:11, B. De Mezzo via QGIS-Developer < qgis-developer@lists.osgeo.org> a écrit : > Hi Rhea, > > same as Johannes "I am in no way able to officially answer but maybe I > can give some thoughts and rhetoric questions": > > * QGIS is not designed to handle such security restrictions, it is not > its purpose > > * the best way, IMHO, is to limit its network accesses by using > dedicated security software as selinux for linux or advanced firewall > configuration for windows > > * the best to discuss these features is "to create QGIS Enhancement > Proposals at https://github.com/qgis/QGIS-Enhancement-Proposals/issues." > > Regards. > > Le 03/11/2023 à 09:35, Johannes Kröger (WhereGroup) via QGIS-Developer a > écrit : > > Hi Rhea, > > > > I am in no way able to officially answer but maybe I can give some > > thoughts and rhetoric questions: > > > > To me those improvements sound like good ideas. I am not sure how far > > you could lock down Python extensibility considering the existing API. > > And I am not sure if you are aware of the many ways that a QGIS > > environment might use network calls, e.g. a tool like Proj might > > download grids from the internet in some cases, GDAL might try to > > fetch schemas specified in local files, etc. Sandboxing the system > > from the outside is probably much easier and secure. > > > > Are those 40 extensions existing extensions? Are you aware that you > > can strip out the official repository and use your own instead? > > > > It would probably be best to create QGIS Enhancement Proposals at > > https://github.com/qgis/QGIS-Enhancement-Proposals/issues. > > > > And it would be good to proof commitment to maintaining the new > > features in some way or enter the sustaining membership program with > > significant, recurring contributions so that other developers paid by > > the QGIS project can maintain them. > > > > Cheers, Hannes > > _______________________________________________ > > QGIS-Developer mailing list > > QGIS-Developer@lists.osgeo.org > > List info: https://lists.osgeo.org/mailman/listinfo/qgis-developer > > Unsubscribe: https://lists.osgeo.org/mailman/listinfo/qgis-developer > _______________________________________________ > QGIS-Developer mailing list > QGIS-Developer@lists.osgeo.org > List info: https://lists.osgeo.org/mailman/listinfo/qgis-developer > Unsubscribe: https://lists.osgeo.org/mailman/listinfo/qgis-developer >
_______________________________________________ QGIS-Developer mailing list QGIS-Developer@lists.osgeo.org List info: https://lists.osgeo.org/mailman/listinfo/qgis-developer Unsubscribe: https://lists.osgeo.org/mailman/listinfo/qgis-developer