<div dir="auto">Hi Rhea, <div dir="auto">Adding some points to the very good answers above. </div><div dir="auto"><br></div><div dir="auto">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. </div><div dir="auto"><br></div><div dir="auto">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. </div><div dir="auto">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)</div><div dir="auto"><br></div><div dir="auto">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 </div><div dir="auto"><br></div><div dir="auto"> A few examples</div><div dir="auto"><br></div><div dir="auto">- configure QGIS with a dedicated user agent name and have the IT team filter the trafic they allow using their firewall</div><div dir="auto">- audit the plugins you will use and ship them with your install packages, or deploy an internal repository</div><div dir="auto">- use the awesome "constrained settings" script funded by a french ministry to prevent users from drifting away from this configuration</div><div dir="auto">- 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. </div><div dir="auto">-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. </div><div dir="auto"><br></div><div dir="auto"><br></div><div dir="auto">Another point. I have seen over constrained QGIS based deployments for  "security reasons" .  They showed  up some side effects: </div><div dir="auto">- 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. </div><div dir="auto">- 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.  </div><div dir="auto"><br></div><div dir="auto"><br></div><div dir="auto">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. </div><div dir="auto">(Disclaimer, I have no direct interest here and speak as a steering committee member)</div><div dir="auto"><br></div><div dir="auto">Best regards , and let us know how it goes </div><div dir="auto"><br></div><div dir="auto">Régis </div><div dir="auto"><br></div><div dir="auto"><br></div><br><br><div class="gmail_quote" dir="auto"><div dir="ltr" class="gmail_attr">Le ven. 3 nov. 2023, 10:11, B. De Mezzo via QGIS-Developer <<a href="mailto:qgis-developer@lists.osgeo.org" target="_blank" rel="noreferrer">qgis-developer@lists.osgeo.org</a>> a écrit :<br></div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">Hi Rhea,<br>
<br>
same as Johannes "I am in no way able to officially answer but maybe I <br>
can give some thoughts and rhetoric questions":<br>
<br>
* QGIS is not designed to handle such security restrictions, it is not <br>
its purpose<br>
<br>
* the best way, IMHO, is to limit its network accesses by using <br>
dedicated security software as selinux for linux or advanced firewall <br>
configuration for windows<br>
<br>
* the best to discuss these features is "to create QGIS Enhancement <br>
Proposals at <a href="https://github.com/qgis/QGIS-Enhancement-Proposals/issues" rel="noreferrer noreferrer noreferrer" target="_blank">https://github.com/qgis/QGIS-Enhancement-Proposals/issues</a>."<br>
<br>
Regards.<br>
<br>
Le 03/11/2023 à 09:35, Johannes Kröger (WhereGroup) via QGIS-Developer a <br>
écrit :<br>
> Hi Rhea,<br>
><br>
> I am in no way able to officially answer but maybe I can give some <br>
> thoughts and rhetoric questions:<br>
><br>
> To me those improvements sound like good ideas. I am not sure how far <br>
> you could lock down Python extensibility considering the existing API. <br>
> And I am not sure if you are aware of the many ways that a QGIS <br>
> environment might use network calls, e.g. a tool like Proj might <br>
> download grids from the internet in some cases, GDAL might try to <br>
> fetch schemas specified in local files, etc. Sandboxing the system <br>
> from the outside is probably much easier and secure.<br>
><br>
> Are those 40 extensions existing extensions? Are you aware that you <br>
> can strip out the official repository and use your own instead?<br>
><br>
> It would probably be best to create QGIS Enhancement Proposals at <br>
> <a href="https://github.com/qgis/QGIS-Enhancement-Proposals/issues" rel="noreferrer noreferrer noreferrer" target="_blank">https://github.com/qgis/QGIS-Enhancement-Proposals/issues</a>.<br>
><br>
> And it would be good to proof commitment to maintaining the new <br>
> features in some way or enter the sustaining membership program with <br>
> significant, recurring contributions so that other developers paid by <br>
> the QGIS project can maintain them.<br>
><br>
> Cheers, Hannes<br>
> _______________________________________________<br>
> QGIS-Developer mailing list<br>
> <a href="mailto:QGIS-Developer@lists.osgeo.org" rel="noreferrer noreferrer" target="_blank">QGIS-Developer@lists.osgeo.org</a><br>
> List info: <a href="https://lists.osgeo.org/mailman/listinfo/qgis-developer" rel="noreferrer noreferrer noreferrer" target="_blank">https://lists.osgeo.org/mailman/listinfo/qgis-developer</a><br>
> Unsubscribe: <a href="https://lists.osgeo.org/mailman/listinfo/qgis-developer" rel="noreferrer noreferrer noreferrer" target="_blank">https://lists.osgeo.org/mailman/listinfo/qgis-developer</a><br>
_______________________________________________<br>
QGIS-Developer mailing list<br>
<a href="mailto:QGIS-Developer@lists.osgeo.org" rel="noreferrer noreferrer" target="_blank">QGIS-Developer@lists.osgeo.org</a><br>
List info: <a href="https://lists.osgeo.org/mailman/listinfo/qgis-developer" rel="noreferrer noreferrer noreferrer" target="_blank">https://lists.osgeo.org/mailman/listinfo/qgis-developer</a><br>
Unsubscribe: <a href="https://lists.osgeo.org/mailman/listinfo/qgis-developer" rel="noreferrer noreferrer noreferrer" target="_blank">https://lists.osgeo.org/mailman/listinfo/qgis-developer</a><br>
</blockquote></div></div>