2022 年 6 月 7 日〜 8 日 : データ分析、データベースをテーマに Data Analytics ＆ Database OnAir 開催

2022年5月31日火曜日

Data Analytics OnAir / Database OnAir では、Google Cloud のデータ分析・データベース製品の活用方法、最新情報、パートナー様による実践的なお話をお届けします。詳細・お申し込みはこちら 6 月 7 日（火）配信テーマ : 一歩深堀り SQL・データガバナンス・BigQuery で学ぶ SQL（中級編）・BI ツールから一歩踏み込んだ SQL 文とは・データ利用者、データ管理者視点でのデータガバナンスについて
6 月 8 日（水）配信テーマ : AlloyDB 特集・先日の Google I/O で発表された PostgreSQL と互換性を持つフルマネージド型のデータベースサービス「AlloyDB for PostgreSQL」について詳しくご紹介・AlloyDB for PostgreSQL 概要とアーキテクチャ・パートナー様による AlloyDB の検証結果・Data Cloud Summit で発表されたデータベース製品最新アップデート
配信日当日はライブ Q＆A を行います。セッションでの疑問や、Google Cloud について聞きたかったことなど、ぜひ直接スピーカーへご質問ください。
《お申し込み》https://goo.gle/3avR5o0こちらのリンクからお申し込みください。
《開催概要》■ 名称 : Google Cloud Data Analytics / Database OnAir
■ 日時 : 2022 年 6 月 7 日（火）8 日（水）10:30 - 12:40
■ 会場 : オンラインにて開催※ スピーカーおよびセッションの最新情報は、お申し込みサイトをご確認ください。
■ 主催 : グーグル・クラウド・ジャパン合同会社
お問い合わせGoogle Cloud Data Analytics OnAir 事務局email : googlecloud-da-japan@google.com
Takuo Suzuki - Developer Relations Team

Google Developer Groups オーガナイザー募集のお知らせ

2022年5月26日木曜日

GDG とは

Google Developer Groups（GDG）は、Google のテクノロジーに興味をもつデベロッパーのコミュニティです。世界 145 ヵ国以上に支部があり、Android、Chrome、Play、Cloud などのプラットフォームから Flutter や TensorFlow などのフレームワーク製品まで幅広い内容を扱っています。

2022 年現在、日本には 22 の GDG コミュニティがあり、定期的に各地で勉強会やイベントを開催しています。

「普段、一緒に新しい技術を勉強する仲間が欲しい」と思ったことがある方は、ぜひお近くの GDG チャプターを探してみてください。

お住まいの地域に GDG 支部がない、またはコミュニティ活動を新たに始めてみたいという方は、GDG オーガナイザーとして活躍してみませんか？

このような方の参加をお待ちしています :

技術系のコミュニティ活動・イベント企画に興味がある

勉強会を通じて仲間と技術の勉強をしたい

IT 業界で活躍しているメンバーと繋がりたい

エンジニアとしてレベルアップしたい

テクノロジーを使って地域の問題に取り組みたい

例 : 東北 TECH 道場は、震災後の東北の復興活動を、テクノロジーを使って支援できないか、またテクノロジーを使って頑張っている開発者の皆さんを支援できないかと考えてスタートされた取り組みです。石巻、滝沢、仙台から始まり、現在までに 12 の東北各地で道場を開催しています。

GDG が世界規模で開催しているキャンペーンの一部紹介

Google I/O Extended

例年、Google I/O で発表のあったセッションの解説や振り返りなど、プロダクト別のさまざまな情報を共有する報告会が開催されています。

DevFest

毎年秋に GDG が世界規模で開催しているコミュニティイベント。2021 年は全世界で 500 を超えるイベントが開催され、33 万人以上が参加しました。

GDG オーガナイザーインタビュー集

清水さん（GDG 福島）

前田さん（GDG 九州）

Katsu さん（GDG 東京）

辰濱さん（GDG 四国）

詳しくはこちら

GDG オーガナイザーは通年募集しております。
👉 応募はこちら
※応募フォームは英語となりますが、回答は日本語で問題ございません。
お気軽にフォームをご提出ください。

お近くの GDG 支部に参加してみたい方は、こちらからチャプターを検索

お問い合わせ：reisam@google.com

Posted by Reisa Matsuda and Takuo Suzuki - Developer Relations Team

Google I/O 2022 報告会イベント「I/O Extended」が日本各地で開催されます

2022年5月18日水曜日

Google は、2022 年 5 月 11 日から 12 日にかけ、オンラインにて Google I/O 2022 を開催しました。例年、Google Developer Groups（GDG）やその他の IT コミュニティの皆さんが、I/O Extended というイベントを各地で開催しています。今年は、Google I/O 2022 で発表のあったセッションの解説や振り返りなど、プロダクト別のさまざまな情報を共有する報告会がオンラインにて開催予定です。開催される予定のイベントの概要は下記のとおりです。イベントごとにお申し込み方法が異なりますので、参加をご希望の方は、各リンクから詳細をご覧ください。※リンクがない・開催日時が TBC となっている箇所は、イベント情報が確定次第、随時更新されますので今しばらくお待ちください。
イベント概要
GDG およびコミュニティ主催I/O Extended Japan 2022

日時 : 2022 年 6 月 5 日（日）15:00 ～ 18:00
参加方法 : YouTube Live
参加費 : 無料
主催 : GDG 四国、岡山、京都、九州、名古屋、東京

※上記 6 チャプターが本イベントを共催いたします

DroidKaigi: Weekend Chat Vol.22~Vol.25 I/O、今年の新技術

日時 : 2022 年 5 月 27 日（金）20:00 ～ 21:30
参加方法 : YouTube Live
参加費 : 無料
主催 : DroidKaigi

Android Bazaar and Conference 2022 Spring

日時 : 2022 年 5 月 28 日（土）10:30 ～ 16:30
参加方法 : YouTube Live（川崎市産業振興会館から YouTube 配信）
参加費 : 無料

主催 : 特定非営利活動法人日本 Android の会 / 日本 Android の会

共催・後援 : 公益財団法人川崎市産業振興財団

Google 主催

Android Roadshow Day 1 （オンライン）

日時 : 2022 年 6 月 15 日（水）10:00 ～ 12:00

参加費 : 無料

参加方法 : ご参加登録はこちら
* ご参加（ご視聴）にはご登録が必要です

企業主催

※ リンクがない箇所は、情報が入り次第更新していきます。

※ I/O 報告会を開催したいと考えており、本記事に情報を追加してほしい、というコミュニティオーガナイザーの方がいらっしゃいましたら、こちらのフォームから情報をお寄せください。

皆さまのご参加を心よりお待ちしております。

Posted by Takuo Suzuki - Developer Relations Team

Apps Script connector for AppSheet についてのお知らせ: Google Workspace でワークフローを自動化する

2022年5月16日月曜日

この記事はシニアスタッフソフトウェアエンジニア、Mike Procopio による Google Developers Blog の記事 "Announcing the Apps Script connector for AppSheet: Automate workflows for Google Workspace" を元に翻訳・加筆したものです。詳しくは元記事をご覧ください。code { background-color: transparent } この度、Apps Script connector for AppSheet をリリースしました。これにより、ノーコードの AppSheet アプリから Apps Script コードの関数を呼び出せるようになります。AppSheet アプリから Apps Script の機能にアクセスできるようになるので、AppSheet アプリでできることが大幅に増えます。たとえば、AppSheet アプリと Google Workspace を組み合わせて、ドライブ、ドキュメント、スプレッドシート、Admin SDK などの Workspace API を利用すれば、Apps Script を使ってワークフローを自動化できます。また、YouTube、Google アナリティクス、BigQuery などのその他の Google サービスと組み合わせることもできます。 Google AppSheet AppSheet は、カスタムのアプリやワークフローをノーコードで開発し、ビジネスプロセスを自動化するための Google のプラットフォームです。これを使うと、コードを書くことなく、エンドツーエンドのアプリを開発してデプロイし、自動化を行うことができます。

Google Appsheet でアプリの定義を編集する

ノーコードの概要 Apps Script コネクタ機能の説明に入る前に、 ノーコードの意味について考えてみましょう。AppSheet などのノーコード型プラットフォームを利用すると、 シチズンデベロッパー がウェブベースのユーザーインターフェースを使い、データの解析を通して、短時間で自動的にアプリを開発できます。通常は、データソースとして、Google スプレッドシート、MySQL、Salesforce、その他のデータベースを利用します。こういったアプリの作成には、従来のソフトウェアエンジニアリングの経験は不要です。そのため、幅広いスキルを持つビジネステクノロジストやアナリストがアプリを開発して、業務を簡易化したり、効率化したりできます。 AppSheet のようなノーコード型プラットフォームでは、コードを書いてアプリを動かすのではなく、ウェブベースのエディタ UI でアプリの動作を定義します。たとえば、アプリはどう動作すべきか、どんなデータソースを使うのか、データにはどんな意味があるのか、ユーザーにどんな UI を表示するのか、どんなイベントを管理するのか、イベントの発生時にどんなアクションを実行するのかなどを指定します。そのアプリは、UI を含むエンドツーエンドのデータ駆動型アプリとして本番環境にデプロイします。これはすべて、実際のコードを「書く」ことなく実現できます。通常のウェブアプリやネイティブアプリにしか見えないので、エンドユーザーが違いを意識することはありません。ノーコードが効果的な理由ノーコード型プラットフォームは、大部分のアプリで実際に効果的に機能しています。その理由は、多くのアプリの機能が非常に似かよっているからです。特に、社内のビジネスプロセスを扱うアプリはよく似ています。このようなアプリには、多くの共通点があります。データを格納するデータソース、データ「レコード」という概念、データの収集や編集を行う UI やフォーム、ユーザーに固有なデータ表示画面、データ変換を定義する式、データが変更されたときに実行されるアクション、管理者による権限の制御などです。例として、社員の出張申請書を作成したり承認したりするアプリを考えてみましょう。このアプリには、経費報告書を作成したり承認したりするアプリとの共通点がたくさんあります。どちらのアプリでも、社員がレコードを作成し、そのレコードに対して審査や追記が行われ、変更が発生するとユーザーに通知され、最終的に申請は完了してクローズされます。同じように、社員に貸与されるコンピュータ機器を追跡する社内アプリとの間にも、多くの共通点があります。たとえば、汎用的な在庫追跡、フルフィルメント、注文システムなどです。ノーコード型プラットフォームの課題は、常に表現力と高レベルの抽象化とのバランスを取る点にあります。幸いにも、データ、データライフサイクル、プロセスで想定される中核部分をしっかりと理解してしまえば、ビジネスプロセスはほぼそれに従います。この領域でノーコード型プラットフォームが効果的なのは、そのためです。しかし、アプリの要件が、ノーコード型プラットフォームでできること以上に広がることもあるかもしれません。新しい Apps Script コネクタは、ノーコード型アプリの表現力（機能）を大幅に高めます。そのため、要件やビジネスプロセスが進化しても、それに対応してアプリを強化することができます。 Google Workspace と Workspace API と Apps Script Google Workspace は、Google のクラウドベース生産性スイートです。これを使うと、あらゆる規模のチームが連携して制作や共同作業をすることができます。皆さんにとって、Gmail、カレンダー、ドライブ、ドキュメント、スプレッドシート、スライドなどのたくさんのアプリはおなじみのものでしょう。各アプリには充実したデベロッパー API も搭載されており、アプリのデベロッパーがプログラムから機能を利用できるようになっています。たとえば、ドライブ API を使うと、ユーザーがファイルをアップロードしたりダウンロードしたりするコードを作成できます。Gmail API ならメッセージ機能を統合でき、Google ドキュメント API ならスクリプトから Google ドキュメントを編集できます。

Chat、Gmail、ドキュメントのプレビューを組み込んだ Google Workspace を使う

Apps Script は ローコード 型プラットフォームで、これを使うと、Google Workspace の統合、自動化、拡張を行うビジネスソリューションをすばやく簡単に開発できます。使いやすい高レベルな API の「ラッパー」が提供されているので、Google Workspace や外部サービスとのカスタム統合が可能です。さらに、Apps Script を使うと、YouTube、Google アナリティクス、BigQuery などの Google のサービスを組み込むこともできます。これは充実したプラットフォームであり、スクリプトを書くことで、複雑なビジネスロジックやマクロを実装したり、サードパーティベンダーのデータ交換システムや機械学習分類サービスなどの外部サービスを呼び出したりできます。

Google Apps Script コードエディタでスクリプトを編集する

Apps Script connector for AppSheet の紹介今週リリースされた Apps Script connector for AppSheet が、AppSheet、Apps Script、Google Workspace、そして Google Workspace の多くのデベロッパー API のすべてをつなぎます。これにより、Apps Script の関数を呼び出してデータを渡せるようになるので、AppSheet を使ったノーコード型アプリでできることが大幅に広がります。これは、 ノーコード （AppSheet）と ローコード （Apps Script）の橋渡しをする機能と考えることもできるでしょう。重要なことは、Apps Script スクリプトを書く人は、スクリプトを呼び出すノーコード型 AppSheet アプリの作成者と同じでなくてもよい点です（ほとんどの場合は、違う人でしょう）。 Apps Script デベロッパーから見れば、この機能によって、いくつかの重要な可能性が開かれることになります。AppSheet の特に大きなメリットは、UI を含む実際のエンドツーエンドアプリ（フロントエンド）を簡単にデプロイできることです。既存の Apps Script コードを呼び出せる新機能を使えるので、ノーコード型 AppSheet アプリを作成したり、それを使って既存のフロントエンドを置き換えたりするという選択肢がゲームチェンジャーになる可能性があります。 Apps Script connector for AppSheet の使用 AppSheet でこれを設定するのは簡単で、スクリプト自体を除けば、他にコードは必要ありません。基本的な考え方としては、アプリの作成者が AppSheet の「タスク」を設定して、呼び出したい Apps Script スクリプトを選びます。タスクとは、AppSheet Automation がトリガーされたときに実行されるアクションを指します。通常、このようなアクションは、AppSheet のデータソースの特定のデータ行に対して実行されます。たとえば、アプリのエンドユーザーが新しいデータレコードを作成したときに、自動処理をトリガーすることができます。また、Apps Script 関数のパラメータに渡す値は、アクティブなデータレコードの値に基づいて指定することもできます。

Google AppSheet で自動処理タスクを編集する

これは、次の 5 つの手順で設定できます。

AppSheet で [Automation] 画面を選択し、新規 ボット を作成して、管理するイベントを関連付けます。最後に、 タスク で [Call a script] オプションを選択します。

AppSheet の自動処理タスクを設定し、Apps Script 関数を呼び出す

続いて、[Apps Script Project] で呼び出すスクリプトを選択します。このコードは、Apps Script エディタを使って作成し、アプリ作成者の Google ドライブに格納されます（他のユーザーが共有したものでも構いません）。

呼び出す Apps Script プロジェクトを Google ドライブから選択する

プロジェクトを選択すると、Apps Script プロジェクト内の呼び出し可能な関数の一覧が [Function name] ドロップダウンに表示されます。ここで、AppSheet から呼び出す関数を選択します。

呼び出す関数を選択すると、パラメータ（関数を呼び出すときに渡す追加データ）の一覧が表示されます。

logTravelRequestUpdate() Apps Script 関数に渡すパラメータが表示される

関数の各パラメータについて、AppSheet の Expression Assistant を使って、自動処理を呼び出すときにパラメータとして渡す値を指定します。式では、単なる AppSheet アプリのデータソース列を使うことも、それよりも複雑な関数や複数の列の計算結果を使うこともできます。

AppSheet の Expression Assistant を使って Apps Script 関数のパラメータに渡す値を選択する

最後に、AppSheet エディタでタスクを保存します。[Save] ボタンを使用してください。これで完了です。自動処理がトリガーされると（ユーザーが新しいデータ行を追加したときなど）、AppSheet の自動処理エンジンが指定した Apps Script 関数を呼び出します。その際に、式を評価した値が関数の引数として渡されます。関数呼び出しの詳細は、AppSheet の Automation Monitor から確認できます。サンプルコード次に簡単なサンプルを示します。上のスクリーンショットで紹介した Travel Request Tool AppSheet アプリに基づくもので、実際に試してみることができます（下のサンプルスクリプトのセクションで、別の例も紹介します）。次のコードは、社員の出張申請書の詳細情報を、「監査ログ」を模した Google ドキュメントに書き込む Apps Script 関数です。ここでは、Apps Script で利用できる DocumentApp ラッパーライブラリを通して Google ドキュメント API を使っています。 TravelRequestAuditLogger.gs function logTravelRequestUpdate(RequestDate, Requestor, Origin, ...) { var TRAVEL_REQUEST_AUDIT_LOG_DOCID = 'your_docid_here' var doc = DocumentApp.openById(TRAVEL_REQUEST_AUDIT_LOG_DOCID) var body = doc.getBody(); var dataParagraph = body.insertParagraph(0, ''); var headerText = dataParagraph.appendText('*** NEW AUDIT LOG ENTRY ***\n'); headerText.setBold(true); // Add in the audit log entry metadata. dataParagraph.appendText('New Travel Request Tool audit log entry...\n'); dataParagraph.appendText('RequestDate: ' + RequestDate + '\n'); dataParagraph.appendText('Requestor: ' + Requestor + '\n'); dataParagraph.appendText('Origin: ' + Origin + '\n'); // ... additional values here to append to Google Doc }

この関数が呼び出されると（新しい出張申請書が作成されて AppSheet の自動処理から呼び出される場合など）、AppSheet から渡された値に応じたテキストが Google ドキュメントに追加されます。ドキュメントが更新されると、次のようになります。

Apps Script の Google ドキュメント API と AppSheet から渡された値を使って作成した Google ドキュメントの出力例

スタートガイドすぐに使ってみたい場合やコミュニティのサポートを受けたい場合に役立つリソースの一覧を作成しています。

サンプルスクリプトこの機能を使ってみる際に役立つ 3 つのサンプルスクリプトを紹介します。サンプル Google Workspace プロジェクト - ドキュメント、スプレッドシート、スライドの作成とメールの送信カレンダーイベントの作成 - カスタマイズ可能なカレンダーイベントの作成インタラクティブ Chat メッセージの送信 - リンクを開くメッセージやイメージを表示するメッセージを Google Chat で送信この機能を発表できたことをとてもうれしく思っています。皆さんが Google Workspace で作るものを見るのが楽しみです。今後も AppSheet や Google Workspace プラットフォームのお知らせを受け取りたい方は、デベロッパーニュースレターへの登録をお願いします。 Eiji Kitamura - Developer Relations Team

改ざんできないビルドでソフトウェアサプライチェーンのセキュリティを改善する

2022年5月13日金曜日

この記事は Google オープンソースセキュリティチーム（GOSST）、Asra Ali、Laurent Simon による Google Online Security Blog の記事 "Improving software supply chain security with tamper-proof builds" を元に翻訳・加筆したものです。詳しくは元記事をご覧ください。code { background-color: transparent }
悪意のあるソースファイルを使って悪意のあるアーティファクトを注入し悪意のあるアーティファクトをアップロードしますTekton ChainsGitHub Actions ワークフローSigstoreSLSA 3

来歴

SLSA（「Supply-chain Levels for Software Artifacts」）は、ソフトウェアアーティファクトのサプライチェーンレベルを表すフレームワークで、開発サイクル全体でプロジェクトの完全性を維持するためのものです。ユーザーは、リリースされたソフトウェアの最終製品をソースまでさかのぼることができます。高い SLSA レベルを実現することで、アーティファクトがデベロッパーの意図したものであることを示す信頼性が向上します。

このブログ投稿では、ビルドの来歴に注目します。ビルドの来歴は、ユーザーにとって重要なビルド情報を提供します。たとえば、誰がリリースプロセスを実行したのか、このビルドアーティファクトは悪意のある改ざんに対して保護されているか、といった内容です。ソースコードの保護方法を表すソースの来歴については、今後のブログ投稿で触れたいと思いますので、ご期待ください。

偽造できないビルド来歴を生成する Go プロトタイプ

改ざんできないビルドの証拠を作成し、ユーザーがそれを検証できるようにするには、以下のことが必要です。

ビルドプロセスから来歴生成処理を分離する
ワークフローに干渉するメンテナから分離する
来歴の検証時にビルダーの身元を確認できる仕組みを提供する

最初の 2 つのポイントに記述されている分離を行うことで、ユーザーは来歴が忠実に記録されたものであるという信頼を得ることができます。これが保証されたエンティティを、信頼されたビルダーと呼びます。

私たちの Go プロトタイプは、3 つの課題すべてを解決します。加えて、ビルドは信頼されたビルダーの中で行われます。これは、ビルドで SLSA 3 の一時性要件と分離要件が達成されていることを示す保証になります。

機能の仕組み

信頼されたビルダーは、次の手順で作成します。信頼されたビルダーは、ビルドとメンテナの干渉から分離された環境で来歴を生成するために必要になります。

ステップ 1: GitHub ランナーで再利用可能なワークフローを作成する

GitHub の再利用可能なワークフローを利用すると、メンテナの呼び出し元ワークフローとビルドプロセスの両方から分離した仕組みを実現できます。このワークフローで Github Actions を使い、それぞれのジョブについて仮想マシン（VM）の新しいインスタンス（これをランナーと呼びます）を作成します。別の VM を作成することで、信頼されたビルダーに必要な分離を実現します。その結果、複数の異なる VM によってプロジェクトがコンパイルされ、SLSA の来歴が生成されて署名されます（下の図を参照）。

GitHub にホストされたランナーでワークフローを実行することで、実行するコードが実際に意図したワークフローであることが保証されます。セルフホストのランナーでは、この点は保証されません。このプロトタイプでは、ワークフローで定義された厳密なコードを実行するために、GitHub を利用しています。

再利用可能なワークフローでは、メンテナから干渉を受ける可能性もなくなります。この仕組みがない場合、メンテナがビルダーに干渉するようなワークフローを定義する可能性があります。再利用可能なワークフローを扱う唯一の方法は、呼び出し側のワークフローに公開される入力パラメータを使うことです。そのため、メンテナが環境変数、ステップ、サービス、デフォルトによって情報を改変することはできなくなります。

この手法では、いずれかのジョブ（ビルドステップなど）が、別のジョブ（来歴ステップ）によって使われる他のアーティファクトを改ざんする可能性をなくすため、信頼されたチャンネルを使ってデータの完全性を維持しています。ジョブ出力を使ってハッシュを送信し（サイズ制限があるため）、そのハッシュを使って信頼されていないアーティファクトレジストリを通して受け取ったバイナリを検証します。

ステップ 2: OpenID Connect（OIDC）を使って外部サービス（Sigstore）に対してワークフローの身元を証明する

OpenID Connect（OIDC）は、ウェブの ID プロバイダ（Google など）で広く使われている標準で、サードパーティに対してユーザーの身元を証明します。現在の GitHub のワークフローは、OIDC をサポートしています。ワークフローが実行されるたびに、ランナーは GitHub の OIDC プロバイダからの一意な JWT トークンを生成できます。このトークンには、ワークフローの身元に関する検証可能な情報が含まれています。たとえば、呼び出し元リポジトリ、コミットのハッシュ、トリガー、現在の（再利用可能な）ワークフローのパスと参照などです。

ワークフローは、OIDC を使って Sigstore の Fulcio ルート認証局に対して自身の身元を証明します。Sigstore は、外部の検証サービスとして振る舞います。Fulcio は、ランナーで生成された一時的な署名鍵を証明する短命の証明書に署名し、それをワークロードの身元と結びつけます。来歴への署名記録は、Sigstore の透明なログ管理サービスである Rekor で保持されます。この署名証明書を信頼性アンカーとして使うと、ユーザーが来歴の正当性や来歴が偽造できないことを検証できます。来歴は、信頼されたビルダーの中で作成されている必要があります。

検証

ユーザーは、以下の手順でアーティファクトと署名された来歴を検証できます。

対応する Rekor ログエントリを検索し、署名を検証する
署名証明書から信頼されたビルダーを抽出し、その身元を確認する
来歴情報が想定されるソースとビルドと一致することを確認する

詳しくは、公式リポジトリの実例をご覧ください。

ユーザーは、以上の手順を経ることで、信頼されたビルダーによって来歴で示されたコミットのハッシュから生成されたバイナリであるという保証を得ることができます。来歴に含まれる情報が偽造できないことは確かなので、ビルドの「レシピ」を信頼することができ、ソースまでさかのぼってアーティファクトの正当性を追跡することもできます。

補足 : 鍵なし署名

この手法には、追加のメリットがあります。それは、メンテナが署名に使う暗号鍵の管理や配布をする必要がないため、鍵の管理という悪名高い難題を回避できることです。OIDC プロトコルでは、ハードコードされた長期間有効なシークレットを GitHub に格納する必要はないため、不適切な鍵管理によって SLSA の来歴が無効になるという問題が起きる可能性はありません。バイナリアーティファクトがしかるべき来歴を生成した信頼されたビルダーでビルドされたことは、OIDC を利用するだけで検証できます。

次のステップ

SLSA フレームワークを活用すれば、大規模環境でソフトウェアのサプライチェーンの完全性を確実に保証できることが実証されています。このプロトタイプから、人気の CI/CD システムの最新機能やオープンソースのツールを使えば、考えられている以上に簡単に高い SLSA レベルを実現できることがわかります。改ざん防止（SLSA 3 以上）に対応したビルドサービスの採用が増えれば、オープンソースエコシステムはより充実し、現在のサプライチェーンにおける簡単に悪用できる脆弱性を 1 つクローズすることにつながります。

ぜひこの機能を試し、採用することをおすすめします。また、プロジェクトへの改善要望も歓迎します。フィードバック、コメント、提案は、slsa-github-generator-go と slsa-verifier のプロジェクトリポジトリからお送りください。これから数週間のうちに、v1 を正式リリースする予定です。

今後の投稿では、安全なリポジトリ設定を証明する偽造できないソース来歴を追加する方法や、他のビルドツールチェーンやパッケージマネージャなどで同じ手法を使う方法について紹介したいと思います。お楽しみに！
Eiji Kitamura - Developer Relations Team

ウェブサイト、アプリ、サーバーで OAuth 2.0 トークンを使用する

2022年5月12日木曜日

この記事はテクニカルライター、Peter Jacobsen による Google Developers Blog の記事 "Use OAuth 2.0 tokens on your website, app, and servers" を元に翻訳・加筆したものです。詳しくは元記事をご覧ください。code { background-color: transparent }

OAuth 2.0 は、インターネットでトークンベースの認可を行うためのオープンな標準認可フレームワークです。OAuth 2.0 のアクセストークンは、OAuth 2.0 クライアントがリソースサーバーにリクエストをする際に使用する文字列で、ユーザー ID などの情報を OAuth 2.0 クライアントから隠蔽します。リソースサーバーにリクエストをする際には、アクセストークンのみを使用します。オフラインリフレッシュトークンアクセストークンは一定時間で有効期限が切れ、関連する API リクエストに利用できない無効な認証情報になります。トークンに関連付けられたスコープに対してオフラインアクセスをリクエストする場合、アクセストークンを更新することができます。このとき、ユーザーにパーミッションを要求するプロンプトを表示する必要はなく、ユーザーがそこにいる必要もありません。リフレッシュトークンの有効期限は、アクセストークンよりも少し長くするというのがベストプラクティスです。たとえば、アクセストークンの有効期限を 30 分に設定する場合、リフレッシュトークンの有効期限は 24 時間またはそれ以上にします。詳しくは、アクセストークンの更新（オフラインアクセス）をご覧ください。オンラインアクセスアプリによっては、短い間隔でユーザーを再認証するリクエストをする可能性があります。その場合は、リフレッシュトークンではなくアクセストークンのみを使います。こういったアプリは、リフレッシュトークンを使ったオフラインアクセスと見なされるアプリとは違い、オンラインアクセスとなります。詳しくは、アクセストークンの更新（オフラインアクセス）とトークンを更新するをご覧ください。 JSON Web Token（JWT）とトークンの有効期限 Cloud IoT の認証をするには、各デバイスで JWT を作成する必要があります。JWT は、デバイスと MQTT または HTTP ブリッジとの間の、短時間だけ有効な認証に使われます。 JWT は、ヘッダー部、ペイロード部、署名部という 3 つのセクションで構成され、ペイロード部には一連のクレームが含まれています。ヘッダー部とペイロード部は、JSON オブジェクトを UTF-8 のバイト列にシリアライズして Base64 URL エンコーディングでエンコードしたものです。 JWT のヘッダー部、ペイロード部、署名部は、ピリオドで連結されます。その結果、通常の JWT は次のような形式になります。 {Base64url encoded header}.{Base64url encoded payload}.{Base64url encoded signature} 詳細については、JSON Web Token（JWT）の使用と JWT トークンの有効期限を管理するをご覧ください。一般的なトークンの有効期限のパラダイムトークンの有効期限の管理には、さまざまなポリシーや戦略を利用できます。以下のような方式が考えられます。

HTTP レスポンスをモニタリングして 401 HTTP レスポンスを検出し、適切に対応する

リソースサーバーに HTTP リクエストを行う前に、先回りでトークンの有効期限を確認し、有効性を判断する

リクエストの際に有効なトークンが期限切れして 401 HTTP レスポンスが発生する可能性がある場合に、上記 2 つの戦略を組み合わせて期限切れに対処する

Eiji Kitamura - Developer Relations Team

Chrome 102: ウィンドウコントロールオーバーレイ、さまざまなオリジントライアルの終了、ファイルハンドラとしての PWA など

2022年5月11日水曜日

この記事は Chromium Blog の記事 "Chrome 102: Window Controls Overlay, a Host of Finished Origin Trials, PWAs as File Handlers and More" を元に翻訳・加筆したものです。詳しくは元記事をご覧ください。code { background-color: transparent }特に記載のない限り、下記の変更は Android、Chrome OS、Linux、macOS、Windows 向けの最新の Chrome ベータ版チャンネルリリースに適用されます。ここに記載されている機能の詳細については、リンクまたは ChromeStatus.com の一覧でご確認ください。2022 年 4 月 28 日の時点で Chrome 102 はベータ版です。PC 向けの最新版は Google.com で、Android では Google Play ストアでダウンロードできます。インストールした PC ウェブアプリ向けのウィンドウコントロールオーバーレイウィンドウコントロールオーバーレイは、ウィンドウ全体を覆うようにアプリのクライアント領域を拡張します。この領域には、タイトルバー、ウィンドウのコントロールボタン（閉じる、最大化 / 復元、最小化）も含まれます。ウェブアプリのデベロッパーは、ウィンドウコントロールオーバーレイを除くウィンドウ全体の描画と入力ハンドリングをする必要があります。この機能を使うと、デベロッパーはインストールされた PC ウェブアプリをオペレーティングシステムのアプリのように見せることができます。詳しくは、PWA のタイトルバーのウィンドウコントロールオーバーレイをカスタマイズするをご覧ください。

完了したオリジントライアルChrome で以前にオリジントライアルが行われていた以下の機能は、現在デフォルトで有効化されています。オリジントライアルとして新機能を試して、ユーザビリティ、実用性、有効性についてのフィードバックをウェブ標準コミュニティに提供することができます。以下の項目を含めて、現在 Chrome でサポートされているオリジントライアルに登録するには、Chrome オリジントライアルダッシュボードをご覧ください。Chrome のオリジントライアルの詳細については、ウェブデベロッパーのためのオリジントライアルガイドをご覧ください。Microsoft Edge は、Chrome とは別に独自のオリジントライアルを行っています。詳細については、Microsoft Edge オリジントライアルデベロッパーコンソールをご覧ください。キャプチャハンドル新しいメカニズムにより、アプリケーションが動画キャプチャをする別のアプリケーションに情報を公開できるようにします。これにより、キャプチャするアプリケーションとキャプチャされるアプリケーションを連携できるようになります。たとえば、プレゼンテーションの動画をキャプチャするビデオ会議アプリケーションで、ビデオ会議タブにユーザー向けのコントロールを表示して、キャプチャするタブのプレゼンテーションを操作することができます。ネットワーク状態のパーティショニングサイドチャンネルを使用したクロスサイトトラッキングを防ぐため、ネットワーク状態がネットワークパーティションキーでパーティショニングされます。これは、トップフレームのサイトに加え、フレームのサイトで構成される可能性があります。この「ネットワーク状態」には、接続（H1、H2、H3、websocket）、DNS キャッシュ、ALPN / H2 サポートデータ、TLS / H3 再開情報、Reporting / NEL 構成とアップロード、Expect-CT 情報が含まれます。クロスサイトトラッキングは、ユーザーにとってプライバシーに対する大きな懸念となっています。本機能は、この問題に対処するうえで欠かせない部分の 1 つです。Speculation RulesSpeculation Rules は、ナビゲーション前にプリフェッチできる外部リンクを定義するための柔軟な構文を提供します。また、可能な場合は、プライベートプリフェッチプロキシの使用などの追加の拡張も提供します。Web Bundle によるサブリソースの読み込みこの機能は、複数のリソースをバンドルできるフォーマットを使って大量のリソースを効率的に読み込むための新たなアプローチです（例 : Web Bundle）。今回のリリースに追加されたその他の機能ファイルハンドラ Web App Manifest メンバーファイルハンドラは、ウェブアプリケーションが指定された MIME タイプや拡張子のファイルを扱えることを宣言できるようにします。ユーザーがウェブアプリケーションでファイルを開こうとすると、そのウェブアプリケーションがイベントを受け取ります。PWA をファイルハンドラにするには、Web App Manifest に file_handlers メンバーを追加します。メンバーの詳細については、仕様をご覧ください。inert 属性新しい inert 属性を使うと、DOM ツリーの一部を不活性としてマークできます。不活性なノードは、以下のように動作します。

ヒットテストは、pointer-events CSS プロパティを 'none' に設定した場合と同じように振る舞います。

テキスト選択機能は、user-select CSS プロパティを 'none' に設定した場合と同じように振る舞います。

編集可能な場合、ノードは編集不可のように振る舞います。

ページ内検索の場合、ユーザーエージェントはノードを無視しても構いません。

詳細については、inert の紹介をご覧ください。ローカルフォントへのアクセスウェブアプリケーションで、ローカルフォントとそれぞれのメタデータをエミュレーションできるようになります。この新しい API を使うと、ウェブアプリケーションからローカルフォント内に格納されているテーブルデータにアクセスすることもできるので、カスタムテキストスタックを使ってアプリケーション内にフォントをレンダリングできます。ナビゲーション API新しい Navigation インターフェース（window からアクセス可能）を使うと、アプリケーションでナビゲーションをインターセプトしたり、ナビゲーションを開始したり、アプリケーションの履歴エントリを確認したりできます。これは、window.history や window.location よりも利便性が高く、単一ページウェブアプリケーションのニーズに特化した仕組みを提供します。hidden 属性の新しい until-found 値Chrome で、hidden 属性に新しい値 until-found が追加されます。これにより、ページ内検索、テキストフラグメントへのスクロール、フラグメントナビゲーションで要素が検索可能になります。これらの検索とナビゲーション機能で hidden=until-found 要素内の対象にスクロールする場合、新しく表示されるコンテンツまでスクロールされるように、ブラウザはその要素から hidden 属性を削除し、その要素に対して beforematch イベントを発行します。詳細については、hidden=until-found で折りたたまれたコンテンツにアクセスできるようにする - Chrome デベロッパーをご覧ください。オリジンプライベートファイルシステム拡張機能 : AccessHandleオリジンプライベートファイルシステム（File System Access API の一部）が拡張され、データアクセスのパフォーマンスを改善する新たなサーフェスが加わります。この新しいサーフェスは、ファイルの内容へのインプレース書き込みと排他的書き込みを提供するという点で、既存のものとは異なります。この変更は、フラッシュされていない更新を整合性のとれた形で読み取る機能や、専用ワーカーで同期的に同じ処理を行う機能とともに、パフォーマンスを大幅に向上して新たなユースケースの可能性を開くものとなります。サブリソースの Private Network Access Preflight リクエストターゲットサーバーから明示的なパーミッションをリクエストする CORS Preflight リクエストが、サブリソースの Private Network Access のスケジュール前に送信されるようになります。プリフライトが失敗すると DevTools に警告が表示されますが、リクエストはこれまでどおり実行されます。これは、互換性を破る変更にはならない見込みです。ウェブサイトで新しいプリフライトリクエストが無視されたり失敗したりする場合は、これまでどおり動作します。Private Network Access とは、パブリックなウェブサイトからプライベート IP アドレスや localhost へのリクエスト、またはプライベートなウェブサイト（イントラネットなど）から localhost へのリクエストを指します。プリフライトリクエストを送ることで、ルーターなどのプライベートネットワークデバイスに対するクロスサイトリクエストフォージェリ攻撃のリスクを緩和できます。多くの場合、プライベートネットワークデバイスはこのような脅威から保護されていません。Secure Payment Confirmation API の変更今回のリリースには、Secure Payment Confirmation API への 3 つの変更点が含まれています。具体的には、PaymentMethod() コンストラクタに渡されるデータが変更されます。

新しい必須プロパティ data.rpId。リライングパーティ ID を含めます。現在の実装でこれを指定していない場合、更新する必要があります。

新しい省略可能プロパティ data.instrument.iconMustBeShown。カードアートアイコンをダウンロードできない場合に、プレースホルダーアイコンが使われるようにします。このフィールドを false に設定すると、アイコンがダウンロードできる場合にのみ決済を進められるようになります。デフォルト値は true です。

新しい省略可能プロパティ data.payeeName。呼び出し元が、既存の data.payeeOrigin の代わりに、またはその横に、受取人の自然な名前を表示できるようにします。

requestDevice() の WebHID exclusionFilters オプションHID.requestDevice() に渡す options オブジェクトに exclusionFilters プロパティが含まれるようになります（HID には navigator.hid でアクセスできます）。このプロパティを使うと、ブラウザのピッカーから一部のデバイスを除外できます。これを使うことで、正しく動作しないことがわかっているデバイスを除外できます。これまで、デベロッパーはカスタムのコードで選択されたデバイスをテストし、そのデバイスが動作しない場合、別のデバイスを選択するようユーザーに促す必要がありました。exclusionFilters プロパティ（用語はテキストで検索する必要があります）は、既存の options と同じメンバーを持つオブジェクトの配列です。 requestDevice() の options 引数の使用方法の例を示します。この例では、最初にベンダー ID 0xABCD でデバイスへのアクセスをリクエストします。このデバイスには、usage ページコンシューマ（0x000C）と usage ID コンシューマコントロール（0x0001）のコレクションも含まれている必要があります。プロダクト ID 0x1234 のデバイスは動作していません。const [device] = await navigator.hid.requestDevice({ filters: [{ vendorId: 0xabcd, usagePage: 0x000c, usage: 0x0001 }], exclusionFilters: [{ vendorId: 0xabcd, productId: 0x1234 }], }); サポートの終了と機能の削除このバージョンの Chrome では、以下のサポートの終了と機能の削除が行われます。現在サポートが終了している機能と以前に削除された機能のリストは、ChromeStatus.com をご覧ください。ユーザーアクティベーションによらない PaymentRequest.show() のサポート終了サイトで、ユーザーアクティベーションによらない PaymentRequest.show() を呼び出すことはできなくなります。ユーザーアクティベーションによらない PaymentRequest.show() のトリガーを許可すると、悪意のあるウェブサイトによって不正利用される可能性があります。ユーザーを保護するため、ユーザーアクティベーションが必須となるように仕様が変更されました。購入操作が中断されることがないように、このメソッドの呼び出しは click などのユーザーイベントの内部で行ってください。Firefox は PaymentRequest に対応していませんが、Safari の実装では、すでに show() の呼び出しにユーザーアクティベーションが必須になっています。SDP Plan B の削除WebRTC でセッションを確立するために使われる Session Description Protocol（SDP）は、Chromium では 2 種類の方言 Unified Plan と Plan B によって実装されています。Plan B はクロスブラウザの互換性がないため、削除されます。このバージョンの Chrome では、Plan B が使われると例外がスローされます。この例外を避ける必要があるデベロッパーは、2022 年 5 月 25 日までの逆トライアルに参加できます。12 月に終了した以前の逆トライアルに参加していて、現在のトライアルにも参加したい方は、新しいトークンをリクエストする必要があります。Eiji Kitamura - Developer Relations Team

みんなで学ぼう〜 Google Cloud オンライン体験プログラム〜

2022年5月10日火曜日

学習ツール「Google Cloud Skills Boost」を使って Google Cloud をコミュニティと一緒に学ぶ、無料の初級者向け新プログラムです。今回は BigQuery を中心としたデータ分析に関するラボを扱います。プログラム概要

プログラム期間 : 2022 年 6 月 2 日～ 6 月 30 日

キックオフセッション : 2022 年 6 月 2 日（木）16:00 ~ 18:00
（アーカイブでも視聴可能）

お申し込み : https://cloudonair.withgoogle.com/events/try-together-0602

対象 : Google Cloud を学びたい大学生以上の方

費用 : 無料

実施方法 : オンライン

本プログラム参加者は、Google Cloud Skills Boost を 30 日間無料で利用できます。Google Cloud Skills Boost を初めてご利用いただく方にもご安心いただけるように、6 月 2 日のキックオフセッションで使い方を説明し、いくつかのラボを解説つきで実施します。（本セッションは、アーカイブでもご覧いただけます。セッションに参加できなくても、プログラムに参加して学習することは可能です）。また、学習においての不明点は、期間中に開催されるコミュニティ主催の勉強会やもくもく会に参加してご質問いただけます。そして、Skills Boost のクエストを完了してスキルバッジを取得された方には、先着で Google Cloud 特製グッズなどを獲得できるチャンスがあります。記念品 :

1 スキルバッジを獲得した先着 1000 名様に、Google Cloud 特製トートバックをプレゼント

2 スキルバッジを獲得した先着 200 名様に、Google Cloud 特製トートバックと携帯保護ケースをプレゼント

3 スキルバッジを獲得した先着 30 名様に Google Cloud 特製トートバック、携帯保護ケースと Google Cloud 認定資格試験バウチャー 1 回分をプレゼント

2 つ以上のスキルバッジを獲得、かつ Twitter で #みんなで学ぼうGoogleCloud をつけてコメントしてくださった方から抽選で 10 名様に、Chromecast with Google TV をプレゼント

コミュニティやグループを主催する方、チューターとして参加を希望する方はこちらでご登録ください。また、本プログラムにも必ずご登録ください。コミュニティ主催の勉強会は随時情報を更新していきます。
イベント概要GDG およびコミュニティ主催Google Cloud Study Jam by インフラ勉強会 Part 2