Re: How to restrict database to use specific diskgroup within a Grid configuration

What case is being made for this from a security standpoint?

The data is easily isolated between apps by other means.

To carry it a bit further, security folks are kidding themselves if they think this data is not all commingled on the SAN.

The concept of actual disks/devices being presented to servers has all been smoke and mirrors for some time now.

On Fri, Mar 18, 2022 at 12:01 Sourav Biswas <biswas.sourav_at_hotmail.com> wrote:

> Thanks Martin and Seth.
>
> This came out as a compliance issue, that one DB should not have access to
> disks of other DBs. The intent is to enforce a restriction, so that any
> attempt to create data files to ASM diskgroups belonging to other databases
> should be stopped.
>
> Seth, I have looked into that document about ASM file access control. My
> current environment has 'oracle' as OS User for all DBs. In order to
> implement ACL , I have to make dedicated OS User for each DBs and grant
> them security limits. This is going to be a daunting task, as we have
> around hundreds of such DBs, if not thousands.
>
>
>
>
>
>
> Regards,
> Sourav Biswas
>
> ------------------------------
> *From:* Seth Miller <sethmiller.sm_at_gmail.com>
> *Sent:* Friday, 18 March 2022, 23:18
> *To:* Martin Berger
> *Cc:* biswas.sourav_at_hotmail.com; oracle-l_at_freelists.org
> *Subject:* Re: How to restrict database to use specific diskgroup within
> a Grid configuration
>
>
> https://docs.oracle.com/en/database/oracle/oracle-database/19/ostmg/asm-access-control-diskgroups.html
> <https://nam12.safelinks.protection.outlook.com/?url=https%3A%2F%2Fdocs.oracle.com%2Fen%2Fdatabase%2Foracle%2Foracle-database%2F19%2Fostmg%2Fasm-access-control-diskgroups.html&data=04%7C01%7C%7C81fc01db57e54401060208da09078032%7C84df9e7fe9f640afb435aaaaaaaaaaaa%7C1%7C0%7C637832225084079489%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C3000&sdata=U6wPMCtKInRYhL78MEuuJ0Eb4GOwX0diNipOnpAaqYo%3D&reserved=0>
>
>
>
>
> On Thu, Mar 17, 2022 at 2:21 AM Martin Berger <martin.a.berger_at_gmail.com>
> wrote:
>
>> Hi,
>>
>> I assume you are using Linux and no Exadata or similar.
>> You can assign separate group IDs to the disks of the specific diskgroups
>> and also start the DB instances with different users and group.
>>
>> If you are using PDBs Path_Prefix and Create_File_Dest can partially help
>> - at least for datafiles.
>>
>> hth,
>> Martin
>>
>>
>>
>> Am Mi., 16. März 2022 um 20:58 Uhr schrieb Sourav Biswas <
>> biswas.sourav_at_hotmail.com>:
>>
>>> Hello Everyone,
>>>
>>> Current environment:
>>>
>>> OS: RHEL 7.9
>>> Grid OS User: grid
>>> Grid: 19.14
>>> Oracle OS User: oracle
>>> CDB: 19.14
>>>
>>> We are running multiple CDBs with one PDB each, on a single Grid. As per
>>> our architecture, for every CDB, we have 3 sets of asm
>>> diskgroups(DATA_CDBn,REDO_CDBn,ARCH_CDBn) created.
>>>
>>> For example,
>>> CDB1 database will have DATA_CDB1, REDO_CDB1, ARCH_CDB1 diskgroups
>>> CDB2 database will have DATA_CDB2, REDO_CDB2, ARCH_CDB2 diskgroup
>>>
>>> Since, at ASM level we can see all of the above 6 diskgroups, I would
>>> like to introduce some restrictions to every database to read and write to
>>> their dedicated diskgroups. I want to ensure that even the sysdba privilege
>>> user of a database cannot create datafile on diskgroups belonging to other
>>> database.
>>>
>>> Please advise how to implement this restriction.
>>>
>>>
>>>
>>> Regards,
>>> Sourav Biswas
>>>
>>
>>
>> --
>> Martin Berger Oracle ♠
>> martin.a.berger_at_gmail.com _at_martinberx
>> <https://nam12.safelinks.protection.outlook.com/?url=https%3A%2F%2Ftwitter.com%2Fmartinberx&data=04%7C01%7C%7C81fc01db57e54401060208da09078032%7C84df9e7fe9f640afb435aaaaaaaaaaaa%7C1%7C0%7C637832225084079489%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C3000&sdata=Nj61kapBv7tQbEh%2BhAeRKaOtAzySDnamyRgLxPIln7M%3D&reserved=0>
>> ^∆x http://berxblog.blogspot.com
>> <https://nam12.safelinks.protection.outlook.com/?url=http%3A%2F%2Fberxblog.blogspot.com%2F&data=04%7C01%7C%7C81fc01db57e54401060208da09078032%7C84df9e7fe9f640afb435aaaaaaaaaaaa%7C1%7C0%7C637832225084079489%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C3000&sdata=ilIbxTWVaSle%2F8GtxIwWGFOPEYwCT42lFsYx%2BlPMJo4%3D&reserved=0>
>>
>
> --

Jared Still
Certifiable Oracle DBA and Part Time Perl Evangelist Principal Consultant at Pythian
Oracle ACE Alumni
Pythian Blog http://www.pythian.com/blog/author/still/ Github: https://github.com/jkstill
Personality: http://www.personalitypage.com/INTJ.html

--
http://www.freelists.org/webpage/oracle-l