2022-06-12

【AWS】AWS Service Catalog ～基礎知識編～

AWS

■ はじめに

AWS Service Catalog について
業務で触れたのでメモ。

【１】AWS Service Catalog
　１）利点
【２】用語整理
　１）Product (製品)
　２）Portfolio（ポートフォリオ）
　３）制約
　４）Provisioned product (プロビジョニングされた製品)
【３】設定の流れ
　１）運用者側の設定
　２）利用者側の設定

【１】AWS Service Catalog

https://aws.amazon.com/jp/servicecatalog/?aws-service-catalog.sort-by=item.additionalFields.createdDate&aws-service-catalog.sort-order=desc

より抜粋
~~~~~~~~
AWS Service Catalog では、
AWS での使用が承認された IT サービスのカタログを作成および管理できます。
~~~~~~~~
 => ここでいう「 IT サービスのカタログ」とは、
　　IT管理者が、開発者などに向けて
　　承認済みとして提供するEC2などのAWSサービスをまとめたリスト

 => 個人的には、CloudFormationをラップして
　　AWS環境の実運用において、使いやすくしたサービスのイメージ

１）利点

[1] アジリティとガバナンスの両立を図ったAWS運用ができる

* 環境構築する権限がなくてもProduct を起動できる

※１「アジリティとガバナンス」の例
（権限が低い）開発者が早くサービスを立ち上げたいけど
（権限が高い）IT管理者が対応しなくてはならず、
対応待ちになってしまうっといったことが起きないように
権限が低い開発者でも自分たちでIT管理者許可した範囲で
サービスを立ち上げる

=> 以下のサイトの例が分かりやすかった

https://blog.serverworks.co.jp/tech/2020/03/18/servicecatalog/

[2] CloudFormationテンプレートの管理が可能

* バージョン管理もできるので、前のバージョンに戻すことも可能

【２】用語整理

* 以下、動画の解説。

https://youtu.be/pRQZLNMF0Lo?t=561

１）Product (製品)

* CloudFormationテンプレートをパッケージ化したもの
* バージョン管理も可能

* 「CloudFormationテンプレート」に関する詳細は
　以下の関連記事を参照のこと

https://dk521123.hatenablog.com/entry/2021/10/26/224812

２）Portfolio（ポートフォリオ）

* Product (製品) をまとめた単位
 => e.g. Dev環境やProd環境用ポートフォリオなど
* バージョン管理も可能
* Portfolio の単位でユーザにProduct (製品) の使用を許可

３）制約

* 製品のデプロイ方法を制御。

* テンプレート制約 といった
　製品を起動する際にユーザが使用できるパラメータを制御
 [例] Dev環境ではEC2インスタンスタイプを安いやつしか選べないが
　　Prod環境は、そこそこ高いやつも選べるなど

* 他にも「起動制約」や「通知制約」がある

４）Provisioned product (プロビジョニングされた製品)

* AWS Service Catalog から起動された製品のインスタンス

[例] 製品がEC2を起動するものであれば、EC2インスタンス

補足：一般的な意味の「プロビジョニング」

* コンピュータの設備などのリソースを提供できるよう予測し、
　準備しておくこと

【３】設定の流れ

１）運用者側の設定

[1] Product の作成
 => AWS CloudFormationテンプレートを
　　インポートして、Product を作成
[2] Portfolio の作成
[3] Portfolio へ Product の追加
[4] Portfolio へ制約の追加
 => 必要に応じて、以下の制約を追加する
 + 起動制約 (IAMロールの設定など)
 + テンプレート制約

２）利用者側の設定

[1] Portfolio の インポート

参考文献

https://blog.serverworks.co.jp/tech/2020/03/18/servicecatalog/

AWS Service Catalog ～ AWS CLI ～
https://dk521123.hatenablog.com/entry/2022/06/03/222336
CloudFormation ～入門編～
https://dk521123.hatenablog.com/entry/2021/10/26/224812
AWS Control Tower ～基礎知識編～
https://dk521123.hatenablog.com/entry/2023/01/04/000000
AWS認定～アソシエイト/ソリューションアーキテクト～
https://dk521123.hatenablog.com/entry/2022/03/01/000000

2022-06-09

シングルサインオン～ SAML認証方式～

プロトコル / ネットワーク

■ はじめに

業務でシングルサインオン（Single Sign-On; SSO）のSAML認証について
扱ったので、メモしておく。

【１】シングルサインオン（SSO）
　１）認証方式
【２】SAML (Security Assertion Markup Language)
【３】SAML認証方式の構成要素
　１）SP（Service Provider）
　２）IdP (Identify Provider)
【４】SAML認証方式による認証の流れ
　１）登場人物
　２）認証の流れ

【１】シングルサインオン（SSO）

* 一回（Single）のユーザ認証を行うことで、
　様々なシステムを以降の認証なしで利用できる仕組み

１）認証方式

* シングルサインオンの認証方式は、以下の通り。
~~~~~~~~~~~~~
[1] 代行認証方式
[2] リバースプロキシ方式
[3] エージェント方式
[4] ケルベロス認証方式（Kerberos）
[5] SAML認証方式（フェデレーション方式） <= 今回は、こちらを扱う
などなど
~~~~~~~~~~~~~

補足：IDフェデレーション

* 以下の関連記事を参照のこと

https://dk521123.hatenablog.com/entry/2022/10/18/185246

【２】SAML (Security Assertion Markup Language)

* 読み方は「サムル」
* シングルサインオンを実現するときに使われる
　XML ベースの標準規格

Assertion (アサーション)

cf. Assertion = 断定

* 標準規格「RFC7522」より抜粋

https://datatracker.ietf.org/doc/html/rfc7522

The Assertion, an XML security token, is a fundamental construct of SAML
that is often adopted for use in other protocols and specifications.

アサーション (XMLセキュリティトークン) は、
他のプロトコルや仕様内で使用するためのよく導入されるSAMLの
基本的構造です

 => SAMLにおける「アサーション」とは
　　XMLベースのユーザ認証情報（トークン）といえる。

【３】SAML認証方式の構成要素

* SAML認証方式の構成要素としては、以下の通り。
　１）SP（Service Provider）
　２）IdP (Identify Provider)

１）SP（Service Provider）

* サービス提供者
 => オンラインショップなどのWebサーバ をイメージ

２）IdP (Identify Provider)

* ID プロバイダ。こいつがメイン。
* シングルサインオンでの認証情報を行ってくれるサービス
 => 認証して問題がなければ、アサーションを発行

補足：「d」が小文字の理由

* IDP（Intruder Detection & Protection）などの
　他の用語との誤用を防ぐため

【４】SAML認証方式による認証の流れ

* ごちゃごちゃ書いているが、あんま大したことやってない
 => ググって動画の説明(例えば、以下のサイト)や説明図をみてみると、
　　理解できると思う

https://youtu.be/KUd4xsOAGZ8?t=237

* ポイントとしては、「認証後、IDプロバイダがアクセストークンとして
　アサーションを発行する」（以下「２）認証の流れ」の[5]）ってことだと思う

１）登場人物

[1] ユーザ
[2] サービスプロバイダ (SP)
[3] IDプロバイダ (IdP)

２）認証の流れ

[1] 「ユーザ」が「サービスプロバイダ」にアクセスする
[2] 「サービスプロバイダ (SP)」は認証がまだ済んでいない場合
　　「IDプロバイダ (IdP)」へリダイレクト
[3] 「IDプロバイダ (IdP)」は「ユーザ」へログイン画面を表示
[4] 「ユーザ」は「IDプロバイダ (IdP)」の提供してもらったログイン画面に
　　認証情報を入力
[5] 「IDプロバイダ (IdP)」は認証が問題なければ、アクセストークンとして
　　アサーションを発行する
[6] アサーション付きのレスポンスが「サービスプロバイダ (SP)」に
　　受領され、それが正規なアサーションであれば（※）
　　ユーザ認証されていると判断し、「ユーザ」はログインできる

※正規なアサーションかどうかの判断

* 事前に「サービスプロバイダ (SP)」と「IDプロバイダ (IdP)」で
　設定しておく必要がある

参考文献

https://www.mobi-connect.net/blog/single-sign-on/
https://cybersecurity-jp.com/column/38350
動画
https://www.youtube.com/watch?v=KUd4xsOAGZ8

IAM ～入門編～
https://dk521123.hatenablog.com/entry/2017/02/26/231046
トークン認証～ JWT ～
https://dk521123.hatenablog.com/entry/2022/07/20/000000
トークン認証～ OAuth ～
https://dk521123.hatenablog.com/entry/2022/07/21/000000
IDフェデレーション
https://dk521123.hatenablog.com/entry/2022/10/18/185246

2022-06-06

【SQL】複合キーの重複データを取得することを考える

SQL PostgreSQL Snowflake

■ はじめに

　Snowflakeのデータ取り込みで、
重複データの調査を依頼されたのでメモ。

【０】お題
　補足：単純にそのデータがユニークどうか調べる場合
【１】関連するSQL
　１）GROUP BY
　２）HAVING
　３）自己相関サブクエリ
　４）DISTINCT
【２】サンプル
　１）サンプルデータ
　２）SQL文
　３）出力結果
【３】課題

【０】お題

定義としては、複合キーで制約していないが
運用としては、重複がない複合キーとして
使用しているテーブルに関する重複データを取得する

補足：単純に対象項目がユニークどうか調べる場合

* distinct を使えば可能。

例

-- １）全件カウント
select count(sample_key) from table1;

-- ２）distinct で重複をまとめてカウント
select count(distinct sample_key) from table1;

-- １）と２）の結果が同じであれば、
-- （少なくともテーブルにあるものは）ユニークである
-- そうじゃなければ、ユニークじゃない

【１】関連するSQL

１）GROUP BY
２）HAVING
３）自己相関サブクエリ（データ行を表示させたい場合）
４）DISTINCT（データ行を表示させたい場合）

１）GROUP BY

* 重複行も含めてGROUP BYで纏める

２）HAVING

* 「１）GROUP BY」のデータに対して
　カウントして複数あった（count(*) > 1）場合のみ
　抽出する
 => これで重複のみで絞れる

３）自己相関サブクエリ（データ行を表示させたい場合）

* GROUP BYしているので、指定以外のデータは基本的に取得できない
　そのため、重複行の他のデータも表示させたい場合に
　抽出したデータと自己結合させて、表示する

４）DISTINCT（データ行を表示させたい場合）

* それでも最終的に重複行が表示されてしまうので、
　無理やりDISTINCTで重複を纏める
 => 多分、もっといい方法があると思うが、、、

【２】サンプル

* 試した環境は、PostgreSQL。

１）サンプルデータ

テーブル定義

CREATE TABLE person_tel_list
(
  person_id VARCHAR(10) NOT NULL, -- 複合キーとして使っている項目
  person_tel VARCHAR(20) NOT NULL, -- 複合キーとして使っている項目
  remarks VARCHAR(20) NOT NULL -- 複合キー以外の項目
);

-- データの挿入
INSERT INTO
  person_tel_list (person_id, person_tel, remarks)
VALUES
    ('1234567890', '090xxxxxxxxx', 'Mike')
    , ('1234567891', '090yyyyyyyy', 'Tom')
    , ('1234567892', '090zzzzzzzz', 'Smith')
    , ('1234567890', '090xxxxxxxxx', 'Mike') -- 重複 - PatternA
    , ('1234567892', '090zzzzzzzz', 'Smith') -- 重複 - PatternB
    , ('1234567893', '080xxxxxxxxx', 'Kevin')
    , ('1234567893', '070xxxxxxxxx', 'Kevin') -- 同じ人物だがTELが違う（OK）
    , ('1234567894', '03zzzzzzzzz', 'Ken')
    , ('1234567895', '03zzzzzzzzz', 'Sam') -- 同じTELだが人物が違う（OK）
    , ('1234567896', '080zzzzzzzz', 'Smith')
    , ('1234567890', '090xxxxxxxxx', 'Mike') -- 重複 - PatternA
;

２）SQL文

SELECT
  DISTINCT
  main.person_id,
  main.person_tel,
  main.remarks,
  sub.duplicate
FROM
(
  -- 抽出用サブクエリ
  SELECT
   person_id, person_tel, COUNT(*) AS duplicate
  FROM
   person_tel_list
  GROUP BY
    person_id, person_tel
  HAVING
    COUNT(*) > 1
) AS sub
INNER JOIN
 person_tel_list AS main
ON
 main.person_id = sub.person_id
 AND main.person_tel = sub.person_tel
ORDER BY
 sub.duplicate DESC
;

３）出力結果

"person_id","person_tel","remarks","duplicate"
"1234567890","090xxxxxxxxx","Mike","3"
"1234567892","090zzzzzzzz","Smith","2"

【３】課題

* 前述した「無理やりDISTINCTで重複を纏める」
 => 以下、DISTINCTなしの出力結果。
　（DISTINCTだとremarksを違う値にした場合、対応できない）

DISTINCT なしの出力

"person_id","person_tel","remarks","duplicate"
"1234567890","090xxxxxxxxx","Mike","3"
"1234567890","090xxxxxxxxx","Mike","3"
"1234567890","090xxxxxxxxx","Mike","3"
"1234567892","090zzzzzzzz","Smith","2"
"1234567892","090zzzzzzzz","Smith","2"

参考文献

https://johobase.com/extracts-duplicate-records-sql/
https://qiita.com/necoyama3/items/4c24defd6f504366aebe

文字列関数～ string_agg ～
https://dk521123.hatenablog.com/entry/2021/08/21/000000

■ はじめに

目次

【１】AWS Service Catalog

１）利点

【２】用語整理

１）Product (製品)

２）Portfolio（ポートフォリオ）

３）制約

４）Provisioned product (プロビジョニングされた製品)

【３】設定の流れ

１）運用者側の設定

２）利用者側の設定

参考文献

関連記事

■ はじめに

目次

【１】シングルサインオン（SSO）

１）認証方式

【２】SAML (Security Assertion Markup Language)

【３】SAML認証方式の構成要素

１）SP（Service Provider）

２）IdP (Identify Provider)

【４】SAML認証方式による認証の流れ

１）登場人物

２）認証の流れ

参考文献

関連記事

■ はじめに

目次

【０】お題

補足：単純に対象項目がユニークどうか調べる場合

【１】関連するSQL

１）GROUP BY

２）HAVING

３）自己相関サブクエリ（データ行を表示させたい場合）

４）DISTINCT（データ行を表示させたい場合）

【２】サンプル

１）サンプルデータ

２）SQL文

３）出力結果

【３】課題

参考文献

関連記事