Received: from malur.postgresql.org ([2a02:16a8:dc51::56]) by arkaria.postgresql.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_CBC_SHA384:256) (Exim 4.89) (envelope-from ) id 1fq4JK-0001ge-02 for pgsql-admin@arkaria.postgresql.org; Wed, 15 Aug 2018 22:30:38 +0000 Received: from localhost ([127.0.0.1] helo=malur.postgresql.org) by malur.postgresql.org with esmtp (Exim 4.89) (envelope-from ) id 1fq4JH-0003gl-Tx for pgsql-admin@arkaria.postgresql.org; Wed, 15 Aug 2018 22:30:35 +0000 Received: from makus.postgresql.org ([2001:4800:1501:1::229]) by malur.postgresql.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_CBC_SHA384:256) (Exim 4.89) (envelope-from ) id 1fq4JH-0003gd-HP for pgsql-admin@lists.postgresql.org; Wed, 15 Aug 2018 22:30:35 +0000 Received: from mail-pg1-x52c.google.com ([2607:f8b0:4864:20::52c]) by makus.postgresql.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_CBC_SHA1:256) (Exim 4.89) (envelope-from ) id 1fq4JE-0001vd-C2 for pgsql-admin@lists.postgresql.org; Wed, 15 Aug 2018 22:30:34 +0000 Received: by mail-pg1-x52c.google.com with SMTP id f14-v6so1086759pgv.13 for ; Wed, 15 Aug 2018 15:30:32 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=references:user-agent:from:to:cc:subject:in-reply-to:date :message-id:mime-version; bh=TW3sc7eRMFnoACcqJad9vOUSViTMeZvH+FFpf2bOyDQ=; b=sU4lbRQnytqUA8WLjZcvhZFlsGpNFJNJsr3X25GXr7DgtsjZ3HPd8oXBm57D0l05Tw meGuUPTCdnmXCCbymto2ZD+FzCofuy83DDpxLhiefkMBFM46c4CZWgLCVw2eDAlxmxhd Qz1rjAi8zXkjQYPqcYmYqFfDrMv1YxVhpdf/WgAq6o2bz/U1XKPHbMlBP4FMGZADhlm3 72ot38i2F6FlleHRuDMswqfgDYrYQFyUUweCBhuLFGUmkSEpjbbitJJl+hKUyUL5ZuOf xeEwFAwFWHnGPxYjI/JvdLStY0+MiitLYu9DyYtBUYAH+E+au82c2ufhh8as61OT/Da7 qnvw== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:references:user-agent:from:to:cc:subject :in-reply-to:date:message-id:mime-version; bh=TW3sc7eRMFnoACcqJad9vOUSViTMeZvH+FFpf2bOyDQ=; b=hNkd8oYJAjeBtWUf0Z5FdA+e9VM62Uj606kgmg30aoR5M/jX1BZQtrT1Nxq0LXTkZ+ +cnwqRDaaEoZCBwtvZonf3cfYEUxcc4QLKhoqcQQ98hWAqi9tacE1tNrXEwKObpZEO3Y j2/5BaRDxjuPd2Lea5OGcOwYTkpdOAjWOMeNeM+EfoFonRc+7Tz87kfmCpAKObHo6vwf owRxoSQiEHcQEC69x6+gqIcCVCbUktd1sz1yXyuU9tU8m3kzkmYNZ9SU2pR30C0xS1dQ R76GDD+6d49GP0xUJpoQAicntkI1KmQjZ/pd1IkRKH4NjUpB+iS0Dq6t7tY7zClTJS6U 2/rA== X-Gm-Message-State: AOUpUlFPWI5LmWlyatAKmYfcyjgDywFsdKLBZ+xOSWFIZo5x+bpnrPHU mIGIn7MPDyODONqm5nbAhW+3pD3VFl4= X-Google-Smtp-Source: AA+uWPxyggRfuFzwXGyM1XcjoG/spRHekocdawkKVBg4xZa4YqGTaMTMJeMjYhNYHrpmIa5ceM7okg== X-Received: by 2002:a63:b43:: with SMTP id a3-v6mr26255886pgl.50.1534372230524; Wed, 15 Aug 2018 15:30:30 -0700 (PDT) Received: from tim-desktop (2001-44b8-31f2-bb00-e188-6000-b6ed-80fb.static.ipv6.internode.on.net. [2001:44b8:31f2:bb00:e188:6000:b6ed:80fb]) by smtp.gmail.com with ESMTPSA id d19-v6sm65646078pfm.48.2018.08.15.15.30.28 (version=TLS1_2 cipher=ECDHE-RSA-CHACHA20-POLY1305 bits=256/256); Wed, 15 Aug 2018 15:30:29 -0700 (PDT) References: <20180810194105.GD7840@momjian.us> <20180814195919.GA29140@momjian.us> <20180815145912.GA11573@momjian.us> <10cde505-db4b-bbeb-7d8a-7c4e145c6042@uvic.ca> <20180815192838.GA5005@momjian.us> <20180815202646.GB5005@momjian.us> <20180815205758.GC5005@momjian.us> User-agent: mu4e 0.9.18; emacs 26.1 From: Tim Cross To: Bruce Momjian Cc: Evan Rempel , pgsql-admin@lists.postgresql.org Subject: Re: How to revoke privileged from PostgreSQL's superuser In-reply-to: <20180815205758.GC5005@momjian.us> Date: Thu, 16 Aug 2018 08:30:14 +1000 Message-ID: <87a7pn6z61.fsf@gmail.com> MIME-Version: 1.0 Content-Type: text/plain List-Id: List-Help: List-Subscribe: List-Post: List-Owner: List-Archive: Precedence: bulk Bruce Momjian writes: > On Wed, Aug 15, 2018 at 01:52:43PM -0700, Evan Rempel wrote: >> There are just a ton of configuration elements that the DBAs need to decide on and implement that require >> configuration of components that are outside of the database proper. >> >> It was a worthwhile discussion. One needs to trust the data stewards. > > Agreed. I just wish it had a more positive outcome. ;-) I think the key points to note are 1. At some point in the hierarchy of privileges, there is a need to have confidence and trust in at least one individual who will have (and need) sufficient privileges that restricting them via technology will become impossible as they will have sufficient power to circumvent anything. Typically, it will be more than a single individual to avoid the proverbial 'hit by a bus' risk. 2. Security comes at a cost. That cost is reduced convenience and increased bureaucracy. The challenge is getting the right balance where that cost is kept as low as possible while mitigating the identified risks. There is no one model which will suit all. 3. The principals of minimal privileges and separation of responsibilities is often a useful guideline. I have seen places where a 'Westminster' model is applied (distinct executive (C level), legislative (policy & Governance), judiciary (risk & audit). The real challenge with security is that it isn't actually a technology problem. It is a business problem. The technology can provide mechanisms to help address the issues, but technology alone cannot solve them. Where it becomes challenging is at the cross-over points. The executive should define overall high level strategy and direction, the legislature clarifies and codifies the strategies and business processes to enable staff to make appropriate decisions and the judiciary ensures everyone is playing by the rules. However, these three areas typically have only limited understanding of the technology (knowledge will typically increase as you work down from executive, legislature to judiciary). As DBAs, we need to understand the principals and risks and apply the technology in the best way possible to support the business and the defined strategies. Tim -- Tim Cross