日々のあれこれφ(．．)

もっぱら壁打ち

Google アナリティクス初級者向けコースを受けた

Googleアナリティクス触りたいけど分析するWebサイトとかデータ持っていないしどうしたものかなと悩んでいたのですが、Google アナリティクス初級者向けコースという公式が出す学習コンテンツがあったので利用しました。

内容は動画（複数あるけどいずれも3~7分程度の短さ）×チュートリアル（画面に触れる動画研修だった！）×演習問題×テスト（簡単め）で構成されており、デモアカウントの画面とデータを色々触りながら各画面の見方やできることを一通り知れたのがよかったです。4コース合計5時間くらいとライトだけど薄過ぎないちょうど良い濃さでした。

以下は学習メモです。自分が欲しい情報にフォーカスされているので少し偏ってはいますが、Google アナリティクス初級者向けコース気になっている人の参考になればと思います。

1. Googleアナリティクスの紹介

所要時間：1h

Googleアナリティクスの仕組み、アカウント設定、プロパティやビューといった構成要素の説明など。演習ではビューに対してフィルタを適用させて確認することをしました。

## 1.1 デジタル アナリティクスの利点
* 顧客が購入(CV)に至るまでのプロセスをデジタルでなら計測できる
  - どこからサイトに流入して、サイト内でどんな行動をして、購入に至ったのか
* オンライン広告のデータを分析して、もっとも効果的だったものに注力できる
  - 例. 地域別の売り上げデータを分析し、もっとも売り上げが高かった地域に多く広告を出稿するようにする
* サイトの問題を収集して、不具合の改善に活かす

## 2.2 Googleアナリティクスの仕組み
* アナリティクスのアカウントを作成するやり方
* サイトの各ページにJavaScriptのトラッキングコードを追加する
* これによりユーザーがページにアクセスするたびに、匿名情報が収集される
  - 例. コップ類を販売するページと家庭用品を販売するページのアクセス数を比較ができたり
  - 商品を購入したユーザー数を確認したり
  - ブラウザの設定言語、種類といった情報も収集される
  - どこから来たのか　
* トラッキングコードによって情報が収集される期間を`セッション`
  - トラッキングコードを含むページにアクセスすると開始され、活動がなくなってから30min経つと終了する
  - 再びアクセスすると新しいセッションが始まる
* 特定の条件でデータを見れる
  - 社内トラフィックのを除外したり、デバイス単位で集計したり
* 1度データベースに保存したデータは変更削除ができないので、設定には注意する

## 1.3 Google アナリティクスの設定
* プロパティ
  - 1アカウントに対して複数作れる
  - トラッキングコードに含まれるトラッキングidを使用して、それぞれ個別にデータを収集する。
    - ウェブサイト用、モバイルアプリ用、販売地域別にプロパティを作って特定の地域のデータを確認しやすくしたり
    - 複数のプロパティのデータを集計して表示することはできない
* ビュー
  - 1プロパティに対して複数追加できる
  - フィルタを使用して表示するデータを指定できる
    - 地域ごとのデータが必要な場合には、地域ごとのビューを作成する
    - 外部トラフィックのみ表示したい場合は、新しいビューを作って内部トラフィックを除外するフィルタを作成する
  - Googleアナリティクスの目標も設定できる
    - CV(購入や申し込み数、お問い合わせ数など)をトラックする有益な方法
  - 注意
    - ビューには作成した時点からのデータのみが含まれる
    - 削除後、管理者のみが35日までだったら復元できる

## 1.4 フィルタを使用したビューの設定
今までは動画だったが、動画形式で画面に触りながら進めるチュートリアル
* フィルターの適用までには30分ほどかかる
* test用ビューと本番用ビューを作成し、test用で動作確認したフィルタをmasterに適用させるといった使い方をした
* 一つのビューに複数フィルターが適用される場合は、フィルタ一覧に表示される順序で適用される

2. Googleアナリティクス　インターフェース

所要時間：1h

デモアカウントの各画面を触りながら、レポート画面の操作方法（データの絞り込みなど）やレポートの共有方法、ダッシュボードで自分が見たいデータを一画面に集めることができることを知れます。

## 2.1 アナリティクスの操作
デモアカウントが作成される
* レポートのリアルタイム
  - 特定のグループのユーザーに関するリアルタイムのコンバージョン数を確認できる
    - 例. 1 日だけのプロモーションを実施している場合、そのプロモーションからクリックしてアクセスしたユーザーがコンバージョンに到達しているかどうか
    - 例. リアルタイムレポートのトラフィックから、ソース: directをクリックすると、直接流入した人たちのものに各レポートのデータをフィルタリングできる。選択した状態でコンテンツに移動すると、その人たちがどんなコンテンツを参照しているかを確認したりできる

## 2.2 サマリーレポートについて
デモアカウントのユーザーレポート画面のガイドを参照した

## 2.3 レポート全体について
* ユーザーレポートを元にできることが紹介されていた
  - セカンダリディメンションを指定できる
    - 国単位で表示しているデータに国-使用しているデバイス単位でデータを表示するようにする
  - グラフの形を変えられる。
    - テーブルから円グラフに。指標も選択できる
  - 表で表示されている各エントリ(流入)が行の平均を上回っているか、下回っているかを色でわけで割合を表示する
  - ピボットテーブルで値を比較できる
* ユーザー指標で計測される対象は、「特定の機関にサイトで1回以上のセッションを記録したユーザーの数」になる

## 2.4 レポートの共有
* レポートにフィルタやビューを設定して内容をカスタマイズできる
* サンプリングレートを速度か精度重視するものに設定できる
* サンプリングに関して、ビューフィルターを適用したり、複雑なセグメントを設定している場合、サンプル数が少なく、データ量が少なくなるケースがある

## 2.5 マイレポート一覧とショートカットの設定方法
* 自分が見やすいレポートをカスタマイズすることができる
  - 複数ページを開かなくても見たいレポートに一目でアクセスできるようにする
  - Datadogのdashboardみたいな
* 作ったレポートは他の人と共有したり、テンプレートをアナリティクスユーザーに共有したりできる
* 他の人が共有したカスタムレポートのテンプレートを引用して、そこからカスタマイズを加えたりもできる

3. ベーシックレポート

所要時間：1h

ユーザーレポート、インタレストレポートの見方と設定方法、集客レポートの活用方法や「参照」「メディア」といった用語の説明、行動レポートの見方といった内容でした。

この辺りから面白くなってきます。

## 3.1 ベーシックレポート
ユーザーレポートに関して
* ユーザーの分布
  - 性別や年齢を確認できる
* インタレストレポート
  - 音楽や旅行などウェブコンテンツの種類別にユーザーの好みを表示できる
* これらはターゲットユーザに適切にリーチしているかを確認するのに使える
* これらのレポートを見るためには以下を設定する必要がある
  - 広告向け機能を有効にする
  - データが表示されるのに1日から2日かかる場合がある
* 地域でアクセスされたipアドレスからユーザーがいる地域を匿名で特定できる
  - 例.アクセス数は多いのに直帰率の高い地域は広告やwebサイトの最適化が必要そうだ
動画の後に演習ページがあったのが良かった

## 3.2 集客レポート
* 集客レポートでは、さまざまなチャネルの成果を比較して、高品質なトラフィックやCV発生源を確認できる
  - これらのデータは戦略を練る際にどこに重点を置くか決めるときの参考になる
* メディア: organic(検索エンジン), cpc(広告のクリックによるもの), 参照(検索エンジン以外のクリック) email, none(ブラウザに直接urlを入力してアクセス)
* 参照元: ユーザーをサイトに導入したウェブサイトのurl
  - 例: media: organic, 参照元: google
* 「参照/メディア」の項目から、ユーザー数が多いものを確認することで、有効なトラフィックを特定できる
* 参照元/メディアごとに直帰率を見れる。サイト平均のものと比較できる
  - 直帰率: トラフィック品質の目安
* チャネルレポート: サイトを利用したユーザーが多いトラフィックを確認するのに使う
  - チャネル: 集客のための経路のこと。アナリティクスではメディア別に参照がorganic,social,directなどトラフィックが自動で分類される
  - 独自のチャネルグループを作成できる
* 参照を使うと自分のサイトにリンクしているWebページを具体的に見れる。
  - どこに広告を出せば効果的かわかるため、新たな広告パートナー契約先の候補になる

## 3.3 行動レポート
* ユーザーがサイトのページをどのように利用したのかがわかるレポート。
  - 改善が必要なページや、今後のコンテンツの方針を考える指針となるコンテンツを見つけられる
* ページがディレクトリごと表示される: `/Office/` `/Kids/` など
  - 特定のセクションにあるコンテンツのパフォーマンスを調べるときに役立つ
* 円グラフに切り替えるとユーザーに人気のあるセクションを簡単に表示できる
  - 40%が`/Wearables/`以下にアクセスしている、など
* ランディングページ　にはユーザーが最初に到達したページが表示される
  - ランディングページごとの直帰率なども確認できる
* イベント: ファイルのDLなどユーザーの特定のアクションを追うことができる。(詳しくは上級者コースでと)

4. 基本的なキャンペーンおよびコンバージョントラッキング

所要時間：1h40m

キャンペーンを測定する仕組み、url生成ツールの使い方、CV（ビジネス目標）の設定方法と設定することで見られる情報といった内容でした。

CVの部分だけもともと自分が知りたかった部分というのもあり、動画で紹介されていた内容以上のものも調べたメモが載っています。

## 4.1 カスタムキャンペーンを測定する方法
* キャンペーンタグ: urlにパラメータ形式で設定できる
  - `?utm_content=v1-10dollars-off`
* アナリティクスのトラッキングコードによってリンクから情報が抽出され、ユーザーと行動がキャンペーンと関連づけられる
  - ユーザーがどのマーケティング活動からサイトに到達したのかがわかる
* キャンペーンタグの種類は5つ
  - メディア、参照元、キャンペーン、コンテンツ、キーワード
* コンテンツの使い方
  - ABテストで同じ内容の2種類のニュースレターを配信したとき、どちらがクリック数が多いか検証する時など
* キーワードの使い方
  - 主に有料広告の配信で使われ、設定するときに手動で追加する
* url生成ツールがある

## 4.2　URL 生成ツールを使用したキャンペーンのトラッキング
* キャンペーン名はレポートで表示されたときにわかりやすい名前にする
* スペースは`_`に変換される
* GUIからは一度に1urlずつしか作れないので、たくさん登録したい時はスプレッドシートにまとめてimportする
* キャンペーンタグの検証方法
  - シークレットモードでブラウザを開く
  - 生成したurlをアドレスバーに張り付ける
  - 遷移先のサイトで重要なアクションを行う(申し込みを行ったりなど)
  - リアルタイムレポートでトラフィックが確認できる
  - 集客 > キャンペーン > 全てのキャンペーン　からテスト対象のキャンペーンで絞り込みをし、データが適切に収集されているか見れる

## 4.3 目標の設定によるビジネス成果の測定 [一番知りたかった情報だ]
* 2種類の目標の違い
  - ビジネス目標: ユーザーに行ってもらいたいアクション(購入など)
    - ユーザーがビジネス目標を達成することをCVと呼ぶ
  - アナリティクスの目標: CVのトラッキング機能
    - 目標を設定すると、アナリティクスにはいくつかのCV関連の指標が作成される(CVの合計数、至ったユーザーの割合)
    - 目標達成プロセスも合わせて設定できる。ファネル分析などに使う
* アナリティクスで設定できる目標は、ビューごとに20こまで
* 設定例: ECサイトなのでビジネス目標は購入してもらうこと。なので購入確認ページに到達することを目標と設定
* 目標の設定方法: 以下の項目を設定する
  - (Googleアナリティクスではいくつかテンプレートが用意されている)
  - 目標名
  - 目標スロットid: 1~20までの番号があり、目標を整理するのに役立つ
    - ？設定を消したり編集したりすることはできるのか。消したらidはどうなるのか
    - スロットidは別の目標とまとめるときは別のスロットを選ぶことができる　？
  - タイプを選択する:
    - 到達ページ: 手続き完了など特定のページに到達したとき。これを選んだ時しかファネル分析は行われない
    - 滞在時間: セッションの長さを計測する
    - ビュー数: 1回のセッションで表示されたページ数
    - イベント: 特定のアクションを起こしたとき(音楽の再生、など)
  - 注文完了ページのリンク先urlを入力する
    - 正規表現も使える
    - 確認ボタンみたいなものがあって、ちゃんと計測できる設定になっているか確認できるようになっている
  - [option]金額を設定する
    - ？使い方
  - [オプション]ファネル分析で使うページを入力する
* 目標を設定すると、各レポートでCV率を参照することができる
* Googleアナリティクスの目標は削除できない。記録ステータスをオフにする
* 21個目を作りたくなったら不要になった目標を編集する
  - ただし目標idと目標セットは変更できない
* CVに割り当てる金額について(目標値)
  - ユーザーの目標を金額換算し、その合計金額をレポートに表示できる機能
  - 例. ニュースレターの購読登録をしたユーザーの 10% と契約が成立し、平均取引額が 50,000 円の場合は、「ニュースレターの購読登録」の目標に5000円割り当てる。もし、登録したユーザーの 1% しか契約が成立しない場合は、「ニュースレターの購読登録」の目標には 500 円を割り当てる

## 4.4 Google広告キャンペーンの測定方法
* Google広告(Adwards)とアナリティクスレポートをアカウント連携させることで見えるレポートの紹介

## 4.5 コースの復習と次のステップ
アナリティクスレポートを使って成果を改善する方法の紹介
* 例. 新規ユーザーに対して成果の高いページを確認する方法
  - サイトコンテンツ > 全てのページ　セカンダリディメンションでユーザータイプ(初回orリピーター)を表示
  - 新規ユーザー獲得のサイトコンテンツとキャンペーン戦略を練る際に役立つ
* あまり効果がないランディングページを特定する
  - サイトコンテンツ > ランディングページ　で直帰率を低い順になるようにソートする
* 利用中のキャンペーンのランディングページとマーケティング活動の関係を確認する
  - サイトコンテンツ > ランディングページ　でセカンダリディメンションにキャンペーンもしくは参照/メディアを指定する
  - 離脱の原因となっているランディングページを調べて修正を行える
* キャンペーンの反応をデバイス別に把握する
  - 全てのキャンペーン を表示し、セカンダリディメンションにデバイスカテゴリを指定
* 地域データと目標を使ってキャンペーンの最適化を行う
  - 地域レポートを開き、CVメニューから対象CVを選択し、率の高い順に並び替える

おわりに

各レッスンの終わりについているテスト（10問程度の選択式問題）を80%以上クリアするとこんな感じの証明書がもらえます。

f:id:reiichii:20210112213736p:plain

入門編ですが、Googleアナリティクスが怖くなくなるくらいには分かった気になれました。

体型的に学べる仕組みがあるってありがたいなーって大人になってよく思います笑

Datadogの認証情報について調べたこと

Datadogの設定をTerraformで行うにあたって、application keyとapi keyが求められるのですが、そもそもDatadogにおいてのこれらは一体何なのかよくわかっていなかったことに気付かされました。

以下は調べたことのまとめです。

Application Key

  • API Keyと合わせて使うと、datadogプログラムにapi経由でアクセスできる
  • ユーザーアカウントに紐づき、ユーザーアカウントの権限と同じ権限を持つ
  • 自分が作ったものしかkey valueを確認できない
  • ユーザーのアカウントが無効になった場合はキーも削除される

API Key

  • メトリクスとイベントをdatadogに送信するには、datadogエージェントがAPIキーを必要とする
  • 組織に固有で、管理者ユーザーのみが作れる（5つまでしか作れない。引き上げも可能）
  • 作成者以外のユーザーもkey valueを参照できる
  • ユーザーのアカウントが無効にされても引き続き使える

ベストプラクティス

これらのキーはどう運用していくのがベストなのか。

公式docsでは、ユーザー間で使いまわすことは想定せず、紐付くユーザーが退職したら新しく作り直すことを推奨していました。そうすることで退職ユーザーがキーにアクセスできないようにするためです。

とはいえグループのメールアドレスを用いたサービスアカウントのような使い方も一応想定しているようでした。（認証情報を安全に保管して必要最小限のメンバーのみがアクセスできるよう気をつけてねといったことが書かれていた）

API キーとアプリケーションキー

なので例えばTerraformで管理する時なんかは、アプリケーションキーはサービスアカウントで発行したものを用いるようにし、それをリポジトリのCICDの環境変数に設定することで、その設定にアクセスできる権限を持った人しか値が見れないようにできます。そういう形になるのかな、やっぱり🤔

Datadogで外形監視の設定をした

はじめに

Datadog の Synthetic MonitoringのAPI Testsを使って、APIサーバに外形監視を設定しました。

要件

今回の監視の目的は「問題があったときに素早く気づけ、エスカレーションできるようにすること」なのでとりわけ社外に公開しているエンドポイントを対象に、DBなど周辺コンポーネントをカバーできるエンドポイントをいくつかピックアップしました。

料金

2020.12.28の時点ではAPI Testsは以下のような料金体系になっています。

料金プラン | Datadog

10000リクエストで $7.20/月。年間請求にすると$5/月

1ヶ月を31日(44640min)として、1min間隔で監視を入れるとしたら年間請求計算で

1エンドポイントで44640/10000 * ＄5 = $22.5（1ロケーションの場合※）

のようになります。

※API Testsではエンドポイントを実行するサーバの場所を指定することができます。例えば1min間隔でSingapore、Sydneyロケーションからエンドポイントチェックを行うとなると、2リクエストになります。このロケーションは書いてあるとおりAWS環境なので、サービスと同じリージョンで動かすとリージョン障害で外形が起動せず障害に気づけないといったことも起こりうるかと思います。グローバルで展開しているシステムでなくても、予算に余裕があれば2つ以上のロケーションで行いたいものです。

設定手順

UX Monitoring > Synthetics Tests でAPI Testsの設定が行えます。

f:id:reiichii:20201228190358p:plain

Define requestではurlとヘッダーやリクエストボディの内容を細かく設定できるようになっています。

{{ }} で囲うことで任意の変数を作成することができます。（他のAPI Testsを設定するときにも使いまわせるのかと思いきやできなそうだった）変数の値は入力した文字列以外にも日付や指定した数の文字列といった関数も用意されていました。

入力内容した内容を「Test URL」ボタンを押下することでテストを行うことができます。またそのレスポンス結果をもとに成功の定義が入力されるのがちょっとした感動ポイントでした笑

f:id:reiichii:20201228191416p:plain

入力フォームの右側にTest URLのレスポンス結果が出て、「2. Define assertions」にresponse timeとstatus codeとcontent-typeの成功値のデフォルトが入ります。条件を変えて再度テストするとDefine assertionsの各項目の右側にpassしたかfailedしたかが表示されるので試しながら調節できます。

f:id:reiichii:20201228192011p:plain

「3. Specify test frequency」 で指定された範囲でリクエストの頻度を指定できます。

「4. Define alert conditions」 でDefine alert conditionsで通知を出すタイミングとリトライの設定ができます。例えば画像のような設定だと、1つのロケーション中1つでfailedが出たらすぐにアラートを飛ばすようになっています。またfailedが起きたら3回リトライを行うようにもなっています。

「5. Notify your team」 では通知の設定を指定できます。Monitorsなどと同じように連携設定をしているSlackやPagerDutyも指定できます。（見た目は同じだけど操作感が若干異なるような）

設定を保存すると、保存された直後からリクエストが行われるようになりました。

f:id:reiichii:20201228192956p:plain

f:id:reiichii:20201228193007p:plain

画像にはありませんが、設定画面の右上でリクエストを一時停止したり、Test URLを意図的に実行させるなどもできました。

Datadogへの通知に関しても、failedしてから0minで届いたのが確認できました。

f:id:reiichii:20201228193827p:plain

f:id:reiichii:20201228193837p:plain

failed時の再通知の設定条件も5. Notify your teamの項目で行わなかったり、10分置きに通知するようにしたりなど設定できます。

また今回はやっていませんが、この辺りの設定もTerraformでコード化できるようでした。

datadog_synthetics_test | Resources | DataDog/datadog | Terraform Registry

おわりに

Mackerelなど他のツールは使ったことないので比較はできませんでしたが、とはいえ使い勝手は良さそうでした。リトライ時のリクエストの感覚も指定できるようになったら嬉しいなー

はじめての要件定義

今回は仕事日記です。

仕事で初めてシステムの1機能の要件定義をやることになりました。しかし私は今まで要件はまとまっていて細部や非機能要件を詰めてシステム設計するフェーズからしかやったことがありませんでした。

そこで今回ははじめて要件定義をするにあたって考えたこととして、PM経験が豊富な上司に聞いてみたことと、今回の要件定義のどう進めることにしたかという事を書きます。絶賛進行中なので良い悪いの話はまた別の機会に。

上司に聞いたことから見出したこと

要件定義のゴール

自分たちは何を作るか、依頼側と合意すること。

最終成果物

合意するためのアウトプットを提示する。

eg. 画面定義所(誰が何のために使うのか、権限、ボタンを押すとどうなるのか)

第3章 画面レイアウト

(IPAのドキュメントがありました。今回はここまで厳密にやるつもりはないのですが、何かの参考になるかもしれないのでメモ)

そしてこのアウトプットを作るために、目的の再確認をしたり、現状を把握したり、やりたいことを整理していく必要がある。そういった考えを詰めるのにUMLが使える。とりわけ上司の場合、ユースケース図でシステムがやるところとやらないところを明確にしたりすることをよく行うとのことだった。

UML入門 - IT専科

注意事項

要件をまとめていざ作ろうとすると割りに合わないくらい工数がかかってしまうこともあるので、システム設計のこともある程度一緒に考えていくのが良い。

今回の要件定義の進め方

前提

登場人物に関しては、関係者は社内の人間のみになります。

  • PDM: システムの企画をする人。カレンダーを見ると想像を絶する多忙さ
  • 先輩エンジニア: 同じチームの先輩。今回は私のサポートしてくれるポジションにある
  • 自分: この機能の開発を主体的に進めていく立場にある。今回触ることになるコンポーネントは携わったことがないので中身のことも調べつつやっていくことになりそう

機能に関しては、以下のような状態でした。

  • 以前からやりたいこととしてマイルストーンにあったもの
  • ざっくりとした要望があり、どう形に落とし込んでいくか(要件定義)はシステム側と相談しないと詰められない状態
  • この企画が作られた背景や、あるとどうユーザーにとってメリットになるのか断片的なドキュメントしかないので、チーム移動で途中参戦した自分の場合そこから把握する必要もあった
    • (余談だが、業界柄人の移り変わりも激しいのでこういった長期目線で何をやっていくべきなのかという思想が失われがち)

立てた計画

方針を立てる

ひとまず「要件定義のたたきを作ってPDMに共有。それを元に要件を固めていけるようにする」という方針を立てました。最初の共有までの期限は1週間です。今の段階ではあまり長くやっても正解にたどり着けるものではないのと、システムや機能を考えるにあたって調査の時間が欲しかったので1週間後に設定しました。そしてPDMに共有する前段階として、前日に先輩に共有して意見をもらいます。

共有用のアウトプットのフォーマットを作る

無限に時間を掛けられてしまう領域なので、とりあえずアウトプットのフォーマットを作ることにしました。今回は以下です。

機能の目的に関しては、mtgが途中参戦だったので丁寧に説明してもらう機会がありませんでした。過去ドキュメントを漁った断片情報からこうなのだろうなと思うものはあったのですが、それが合っているか確認するのも兼ねて冒頭に据えます。

想定ユースケースに関しては、とりわけ私の理解が及んでいない部分でした。実は打ち合わせした時に全然話についていけなくて内心軽くパニクってたのですが、この部分を理解していないからだったんだということにフォーマットを作っていて気づきました。 ユーザーの気持ちを考えることはできても、層が自分から離れていることもあり短い時間では浅い理解しかおそらくできないだろうなと思っています。とはいえ考えるうちに少しずつ近づけるようにもなりたいので、まずは自分で考えてそれから「こんなふうに考えてみたんですが、実際はどうなのでしょう」といった形で聞いてみようと思いました。とりわけこの部分を確認するために3日目に先輩に時間をもらうことにしました。 これも無限に悩めてしまうのでアウトプットベースで、3つのペルソナを作ってそれぞれに対して3パターンユースケースを挙げてみました。

最終成果物(画面)のイメージに関しては、今はたたきの時点なので丁寧には作りません。何かしらベースがあった方が話が進むと思うので、ipadでjamboardに絵を描いてリンクを共有する形にしました。jamboardを使うことで、修正をすぐにブラウザに反映させることができるのが良さそうでした。(実際のmtgではまだ試していない)

Google Jamboard: 共同作業に適したデジタル ホワイトボード | G Suite for Education | Google for Education

こんな感じで進めています。

おわりに

要件定義は大事で、ここをしっかりできなければ後々取り返しのつかないことになることはよく耳にしますが、実際どうやっていくのがいいのか、何に気をつけたらいいのかなど、体系的にまとまっていて初心者の手引きになるドキュメントを知りませんでした。各々の地頭を駆使して行われているようなイメージでした(そして実際そうみたいだった)。我流でやるのもいいけど、せっかく先駆者がいるのであればその人たちの学びを参考にして避けられる失敗は避けて進めたいと思っていました。

今後も要件定義をやる機会はあると思うので、なんとなくでやるよりも自分なりに要件定義との付き合い方を掴められるようになりたいものです。

GCPにて本番作業時の権限の切り替え方法について

業務でIAMの権限周りの管理を見直すことになったのですが、とりわけ掲題についてよくわかりませんでした。

結論だけ言うとGoogleグループの切り替えで行うのが主流のようでした。

ただそれにしても懸念点は残るので、以下の視点で調べたことや知っておいた方が良さそうなことをまとめます。

  • 本番、開発環境など複数環境でGCPを使用している
  • チームやIAMを作成する人数が少なく、最小限の権限を意識しつつもある程度の裁量も与えられることが可能

IAMを割り当てられるものの対象

ドキュメントではmemberと呼ばれています。これは以下の四つになります。

  • 個人のGoogleアカウント
  • Googleグループ
    • GCPとは異なる管轄のサービスになる。グループには複数のGoogleアカウントが属している
  • サービスアカウント
    • システムに割り当てるもの。(※今回は対象外)
  • Cloud Identity
  • Google Workspaceadmin

下二つのサービスは初めて聞きました。 AWSはAWSだけで管理できますが、GCPはGCP以外のサービスの知識も求められるので学習コストが高くなりますね。 下二つは料金が発生してしまうので一旦対象外としました。

気になるのが、本番環境にて参照時と作業時で権限を切り替える時の運用方法です。 ドキュメントだけだといまいちよくわからなかったのでコミュニティに聞いてみたところ、Googleグループを使った以下のような使われ方が主流みたいでした。

  • プロジェクトにはGoogleグループに対してIAMロールを設定するようにする
  • 開発者は普段は参照のみ権限が割り当てられたグループに所属している
  • 本番作業時、開発者は実行権限のあるGoogleグループに入り直す
  • 作業終了後、開発者は実行権限のあるグループを抜ける

グループの入り抜けに関しては、設定によって許可制にする(「組織内の誰でも参加をリクエストできる」)こともしない(「組織内の誰でも参加できる」)こともできるようでした。自チームの場合人数の関係で、承認を設けてしまうと承認者がボトルネックになって緊急時に対応が行えなくなってしまうようなことがあったらよくないなと危惧していたのですが、誰でも自由に参加退出できるようにすればその心配はなさそうです。

IAMロールには3種類ある

  • 基本ロール
    • オーナー(roles/owner)、編集者(roles/editor)、閲覧者(roles/viewer)
  • 事前定義ロール
    • 他のリソースへの望ましくないアクセスを防ぐGCP管理のrole
  • カスタムロール
    • ユーザーが設定できるもの

使い方としては、権限が大きい基本のロールは本番権限には付与しません。本番環境のメンバーには、事前定義ロールでできることを必要なものだけに制限したロールを付与するようにし、やりたいことが事前定義ロールでできない場合カスタムロールで自作するといった使い方が想定されています。 なるべく事前定義ロールを使うようにするのは、カスタムロールだと必要に応じて自分達でアップデートしていかないといけないので管理コストが多少できてしまうためです。

また閲覧権限に関して、閲覧のみと言いつつBQやGCSのデータにアクセスできてしまうなど権限が大きいものになっています。不要なデータへのアクセスも防ぎたい時はより制限されたrole/browerという参照権限を付与するのが望ましいです。

フォルダ

複数のプロジェクトをフォルダでまとめて管理することができます。フォルダを利用することにより、Googleグループを各プロジェクトではなくそのフォルダに割り当てることができるようになり、ユーザーの管理をより楽にできます。

？必要な時限定に絞るにはどうしたらいいか

Googleグループの切り替えによって必要な時だけ実行権限を持つようにできることはわかりました。ただ作業終了時に自分から抜けるか、誰かに除外してもらうかしないとずっと実行権限が持ったままになってしまいますよね。

一番望ましいやり方が、1時間など指定した時間が経過したらsession outになるようにすることですが、そういったものをどうやって実現させることができるのでしょうか。

？IAM Conditionsを使えばできる

IAM Conditionsとは特定の条件下でのみ権限を得るように設定できる項目のことです。条件は時間やアクセス元のリソース、IPなど色々ありました。

この機能を使えば実現できそうな気もします。がしかし、ドキュメントの例だと営業時間のみなど固定の日時の設定しかできないみたいです。本番作業は深夜メンテナンスや障害など営業時間以外にも起こりうるのでそれだとちょっと合いません。

この部分に関してはもう少し検証できたらと思うので、実現できそうなやり方があれば追記しようと思います。

おわりに

IAM Conditionsでなんとかやれないものだろうか...

参考資料

公式ドキュメント

非公式だけどとても参考になったドキュメント

Google Cloud APIsの認証の種類と使い分けについて

以前まではAWS環境で開発を行うことが多かったのですが、最近ではGCP環境も結構触っています。

Google Cloud APIを使ったプロジェクトの開発を行う際、私はいつもサービスアカウントキー を作成してそれを読み込ませる形でローカル環境を構築していたのですが、別の人はOAuth 2.0クライアント認証を用いるやり方で開発をしていたと聞きました。

このようにGoogle Cloud APIを使う際には認証のやり方が複数あるのですが、どれをどういう思想で使い分けすればいいのか、はたまた開発者自由でいいのか、認証の設計思想に理解が浅い状態だったので腰を据えてドキュメントを読んだ時のメモです。

Authentication overview  |  Google Cloud

今回の話のスコープ

Google Cloud APIの話になります。Google Maps Platform APIのようなGCP外のサービスは含みません。

認証を知るにあたって出てくる概念

プリンシパル

プリンシパルをうまく和訳して説明するのが難しいのですが、APIを使う主語にあたるものをさしているという認識です。プリンシパルはもっぱら人間か人間以外のもの(サーバーやbotなど)によるアクセスかで種類が分かれます。

  • User accounts
    • 想定: 人間によるアクセス
    • 管理: Googleアカウントを使って行う
  • Service accounts
    • 想定: 人間以外からのアクセス(システムなど)
    • 管理: IAM

アプリケーション

プリンシパルが「"誰が"リクエストをするか」にあたる部分とするなら、アプリケーションは「"どこで"リクエストをするか」にあたる部分を示しています。具体的にはGCEやGAE、GKEやGCP外(誰かのローカル環境)などの実行環境を示すものと思われます。

3種類の認証情報の種類

これらの概念を踏まえた上で、認証の方法としては3種類用意されています。

APIキー

これは一番分かり易いもので、プリンシパルは識別せず、アプリケーションのみを識別するものです。

例えば、そのAPIキーを持っていたら、誰でもGCSの特定のオブジェクトにアクセスできるというようなことを実現できます。

OAuth 2.0クライアント認証

認証時にGoogleアカウントが必要になる、プリンシパルがUser accounts(人間によるアクセス)を想定した認証になっているようです。

サービスアカウントキー

認証時にサービスアカウントと紐づけられたサービスアカウント キーが必要になる、プリンシパルがService accounts(人間以外からのアクセス)を想定した認証になっているようです。認証情報に個人のGoogleアカウントを必要としないので、本番環境のシステムやCICDのような共有しているものに対して使えます。

サービスアカウント には厳密には二種類存在します。

  • デフォルトサービスアカウント
    • GCPのコンピュート系のリソース(GCEやGAE等)にデフォルトで付与されているもので、GCP環境内からAPIを実行するときはサービスアカウント の付与が不要になります。これはGoogle Cloud Client Libraries(Google Cloud APIを呼び出すためのクライアントライブラリ。各言語のものが一通り用意されている)は、サービスアカウントの認証情報を自動的に検索して使用するようになっているためです
  • サービスアカウント
    • デフォルトでないものは全部こちらです。IAMからユーザーが必要に応じて作成します。サービスアカウント キーとは、ここで作ったサービスアカウントで作成または登録をしたキーを、Google Cloud Client Librariesライブラリに読み込ませることで認証を行います

使い分けの戦略について

アプリケーションに必要な実行権限と実行場所を基に何を使うか決めるのが良さそうとのことで、一例が以下のようになります。

  • APIキー
    • 公開データへの匿名アクセス
  • OAuth 2.0クライアント認証
    • エンドユーザーに代わって個人データにアクセスする
  • サービスアカウントキー
    • GoogleCloud環境外のサービスアカウントに代わって個人データにアクセスする
  • デフォルトサービスアカウント(認証情報を渡さなくてもいい)
    • GoogleCloud環境内のサービスアカウントに代わって個人データにアクセスする

おわりに

APIキーはさておき、OAuth 2.0クライアント認証とサービスアカウントキー、開発時はどちらを使うのが好ましいのかわからなかったのですが、ドキュメントを見たところどちらでも良さそうでした。

強いて挙げるとしたら、サービスアカウント にはリソースに対して実行できるアクションを絞ることができるので、権限の検証をしたいときはサービスアカウント キーを設定し、それ以外は開発者個人のGoogleアカウントを使ってOAuth 2.0クライアント認証を行うのがよいのでしょうか。

ただOAuth2.0クライアント認証を使う場合、アクションに制限をつけるためにOAuth scopesの定義が求められたりして、ソースの書き方が変わってくるケースもあるかと思うので本番とできるだけ差異を小さくするのであればサービスアカウント キーを使うようにした方がよいのかなと個人的には思っていたりもします。

開発を行っていくにあたってこういった重要な周辺リソースの思想はちゃんと知っておきたいものです。

CTF入門した

2週間くらい前からCTFを始めました。

CTFとは

Catcher The Flagの略で、相手の陣地にある旗を先取するゲームです。サバゲやeスポーツなどでも出てくる用語ですが私が始めたのはセキュリティ競技CTFです。

セキュリティ競技CTFでは、情報セキュリティの知識を駆使してお題を解いて解答(フラグ)を入手していきます。クイズ形式以外にもチームを組んで相手チームのサーバに侵入して旗を取るなど色々形式はあります。

興味を持ったはいいが周りでやっている人もいなかったので取っ掛かりが掴めなかった私ですが、きなこもちさんのブログが参考になりました！

CTF初心者が考えるCTF入門 - きなこもち。

入門としてやったこと

CpawCTF

  • 大学のプログラミングサークル運営
  • 問題数全23問ほど

少しのググり力で解けるLv.1の問題から、若干ひねってきたLv.2、自力で解けずに諦めて解説を探しにいくLv.3、といった感じでした。まさに入門者にはちょうどいい難易度で普通に楽しめました。

私が全問題解き終わった数日後くらいに証明書が切れてアクセスできない状態が続くようになったのですが、復活するといいな。

picoCTF

中高生向けといいつつ、難しい問題は普通に難しいです。 問題数が多いので今回はジャンルごとに解いていくことにし、今の時点で私はWebアプリケーションを題材にしたWeb Exploitionというジャンルの問題を全13問一通り解き終わったところです。ソース見ればパッと答えが分かるような簡単過ぎる問題から、ちょっとしたバイナリの知識が求められるやや難しいものまであり、とても充実していました。

入門〜初級レベルの問題で使えるテクニック

問題を解く中で知った小技を共有します。問題のネタバレはここでは含まないようにします。

Chrome Developper Tool

「右クリック > 拡張」 で開く、webサービスの開発には欠かせないデバッグツールです。

Cookieを編集する

やり方を調べると拡張機能を使ったものが多く紹介されていましたが、拡張機能を入れなくてもdevtoolでできました。

(写真は問題関係ないページを開いた時のものです)

f:id:reiichii:20201031230238p:plain

Networkの通信を確認する

この画面を開いた状態でページを開くと、他のサイトとどのような通信を行なっているのかが記録されるページです。ページ遷移の最中に実は一瞬だけ別のサイトにリダイレクトしていたり、リクエストヘッダーやボディの中を確認したりなど、何かと使いました。

f:id:reiichii:20201101114432p:plain

debugger

Web系の問題にはJavaScriptを用いた問題も多く出されます。debuggerで変数の中身を確認したり、コードをいじったりなどして調査するのに欠かせません。

f:id:reiichii:20201101115008p:plain

tshark

ネットワーク系の問題ではパケットキャプチャのファイルを渡されて、そこからフラグを探しに行くことが多いです。 tsharkかもしくはwebアプリ版のwiresharkを使ってパケットキャプチャを読めるようにしていきます。

$ tshark -r test.pcap
    1   0.000000 192.168.1.114 → 192.168.1.1  DNS 77 Standard query 0x504d A q28.ctf.cpaw.site
    2   0.001660  192.168.1.1 → 192.168.1.114 DNS 126 Standard query response 0x504d A q28.ctf.cpaw.site CNAME host1.ctf.cpaw.site A 157.7.52.186
    3   2.380278 192.168.1.114 → 157.7.52.186 TCP 78 52852 → 21 [SYN] Seq=0 Win=65535 Len=0 MSS=1460 WS=8 TSval=246798505 TSecr=0 SACK_PERM=1
    4   2.404144 157.7.52.186 → 192.168.1.114 TCP 74 21 → 52852 [SYN, ACK] Seq=0 Ack=1 Win=14480 Len=0 MSS=1460 SACK_PERM=1 TSval=444760454 TSecr=246798505 WS=128
    5   2.404244 192.168.1.114 → 157.7.52.186 TCP 66 52852 → 21 [ACK] Seq=1 Ack=1 Win=131768 Len=0 TSval=246798529 TSecr=444760454

また対応するプロトコルでダウンロードしたファイルの復元も行えます。

問題の中ではパケットキャプチャからhtml,css,jsのファイルを復元してフラグを探すものなどもありました。

$ tshark -r hoge.pcap --export-objects http,/path/to/cpaw

fileコマンド

Binary Exploitation(バイナリ解析)系の問題ではよく分からないファイルを渡されるところから始まりますが、だいたい最初はfileコマンドで実行環境を確認するところから始めることが多かったです。

$ file hoge
hoge: tcpdump capture file (little-endian) - version 0.0, capture length 1869357413)

この場合hogeというファイルがtcpdump capture fileであることが分かります。

stringsコマンド

Binary Exploitation(バイナリ解析)入門その2。バイナリファイルの読める部分を抽出してくれるコマンドです。そんなコマンドあるのかと初めて知って驚きました。このコマンドを実行してうっすら答えが見えてくるような問題もあったのですが、本当に入門レベルの問題だけなんだろうなという気がしますね。

$ strings hoge
a``d
a``Pyr`5
~un6+
JGBFz
rd=h5
00pV
>7 n

一番有名なsqlインジェクション

' OR 1=1 --

例えばログイン名とパスワードを入力するフォームがあるとします。

サーバサイドで入力値を適切にエスケープ処理がされていない以下のようなコードがあった場合、裏側で意図しないsqlが発行されてしまいます。

サーバサイドのコード: SELECT * FROM user WHERE name='%s' AND password = '%s'

[本来のユースケース] ユーザー名: piyoko パスワード: hghghghghghg　と入力した場合

SELECT * FROM user WHERE name='piyoko' AND password = 'hghghghghghg'

ユーザー名とパスワードで検索をかけ、該当するデータが存在した場合入力情報が適切とみなされてログインができます。

[悪用された場合] ユーザー名: ' OR 1=1 -- パスワード: (てきとうな文字列)

  • ' : 最初の閉じ括弧でname = '' を終わらせる
  • OR 1=1 : 任意のsqlを入れられる。この場合はpasswordの代わりにWHERE条件が必ずマッチするように1=1が入れられている
  • -- : これ以降のsqlをコメントとして無効にする。この例の場合 password一致が無効になる

SELECT * FROM user WHERE name='' OR 1=1 -- AND password =

と言った形でログイン情報を知らない人にもログインが行われてしまいます。

上記のような考え方を応用した問題がwebジャンルでは出題されます。

gdb

書いておいて何ですが、Reversing(リバースエンジニアリング)系の問題に関しては、知識が無さすぎて入門に立てていないです。 コマンドを実行しながら解説を辿っても、中々解説者と同じ思考回路を辿れません...。(そもそも逆アセンブリという言葉をはじめて知った。)

おわりに

ひとまずpicoCTFの他のジャンルに手を広げつつ、来年にはビギナーズコンテストなどにもチャレンジできたらいいなと思っています。